Verifying a Release Download

Every Accent CMS release published to github.com/AccentCMS/accent ships with material you can use to confirm a downloaded archive is exactly what our CI produced and has not been altered in transit. None of these checks require a license – there is one binary per platform, and every check applies to every target.

Verify the SHA-256 checksum

Each release includes a checksums-vX.Y.Z.txt file listing the SHA-256 hash of every published archive. After downloading both the archive and the checksums file into the same directory, verify the archive:

# Linux
sha256sum -c checksums-vX.Y.Z.txt --ignore-missing

# macOS
shasum -a 256 -c checksums-vX.Y.Z.txt --ignore-missing

--ignore-missing checks only the archives you actually downloaded and ignores the other targets listed in the file. A line ending in OK means the hash matches; any other result means the archive does not match what was published – do not run it.

Verify the checksums signature

Every release carries a checksums-vX.Y.Z.txt.asc file: the checksums list itself is GPG-signed, so you can detect a tampered checksums file (not just a tampered archive). Signing is mandatory in the release pipeline – a release cannot be published without it.

Fetch the Accent CMS release signing key, check its fingerprint, and import it once:

curl -fsSLO https://raw.githubusercontent.com/AccentCMS/accent/main/release-signing-key.asc
gpg --show-keys release-signing-key.asc
gpg --import release-signing-key.asc

gpg --show-keys must report this fingerprint:

C0197617BAE752019693A17E95377BC8B27FF227

The key file is published next to the releases, so a key that verifies a signature proves nothing by itself; the fingerprint is what ties it to Accent CMS. The install scripts check the same fingerprint automatically.

Then verify the detached signature before trusting the checksums:

gpg --verify checksums-vX.Y.Z.txt.asc checksums-vX.Y.Z.txt

A Good signature line from the key above confirms the checksums file is authentic.

Audit the embedded dependency list

Native binaries embed a compact software bill of materials (SBOM): the exact dependency tree the binary was compiled from, recorded in a dedicated section of the executable (under 4 kB). You can audit a downloaded binary against the RustSec advisory database without any access to our source tree:

# Scan the embedded SBOM for known vulnerabilities
cargo install cargo-audit       # one-time, provides `cargo audit`
cargo audit bin ./accent

# Or just print the recorded dependency tree
cargo install rust-audit-info
rust-audit-info ./accent

Every release binary compiles the same full feature set, so all targets report the same dependency tree for a given version. Releases up to v0.25.0 were the exception for aarch64-unknown-linux-gnu, which carried no SBOM; every target embeds one from the next release on.

macOS Gatekeeper

On macOS, signed and notarized builds let Gatekeeper confirm the binary’s publisher; first-run verification happens online, since a bare command-line binary cannot have the notarization ticket stapled to it. If macOS quarantines a downloaded binary (“developer cannot be verified”), it has not been notarized – verify it with the checksum above and clear the quarantine attribute yourself only if you trust the source:

xattr -d com.apple.quarantine ./accent

Verify the publication attestation

Each release also carries a signed attestation in the Sigstore transparency log, recorded by a workflow in the download repository at publication time after it re-ran the signature and checksum verification above. With the GitHub CLI:

gh attestation verify accent-vX.Y.Z-<target>.tar.gz --repo AccentCMS/accent

Require verification in automation

The install script (install.sh) verifies the checksum and, when gpg is on your PATH, the checksums signature on every run. By default it is best-effort about the ability to verify: if the checksums file or signature won’t download, or the machine has no gpg or sha256sum, it prints a warning and installs anyway, because a hard failure over a transient network error is the wrong trade for a person running a one-liner. A checksum or signature that is present and wrong always fails.

In CI nobody reads the warning. Pass --require-verify or set ACCENT_INSTALL_REQUIRE_VERIFY=1 and every skipped check becomes a failure instead, so a job that installs Accent CMS either verified both the checksum and the signature or did not install at all:

- name: Install Accent CMS
  env:
    ACCENT_INSTALL_REQUIRE_VERIFY: "1"
  run: |
    curl -fsSL -o install.sh https://raw.githubusercontent.com/AccentCMS/accent/main/install.sh
    sh install.sh

Download the script to a file and run it, rather than piping curl into sh: under a shell without pipefail, a failed download pipes empty input into sh, which exits 0.

If you would rather not depend on the machine having gpg at all, the Rust installer does the same verification in-process, with the release signing key compiled in and no way to skip a check:

cargo install accent --locked   # the crate is `accent`; the binary is `accentup`
accentup install                # or: accentup install --version 0.25.0

Our own deploy workflows use accentup, built from crates.io at a pinned version.

What verification does and does not prove

A matching checksum and a good signature prove the archive is byte-for-byte what our release pipeline published, and the attestation adds independent, publicly-logged tamper evidence from publication time onward. None of these prove, on their own, which source revision produced the binary – the attestation covers publication, not the build (builds run in a private repository). The checksum, signature, attestation, and embedded SBOM together let you confirm integrity and audit the dependency set of any binary you run.