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.

Import the Accent CMS release signing key once:

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

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 confirms the checksums file is authentic; verify the key fingerprint against the copy of release-signing-key.asc published in the download repository and on the release notes.

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. The cross-compiled aarch64-unknown-linux-gnu build is the one exception to SBOM embedding – it does not yet carry one.

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

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.