Verify a release

Documents the atlasd v0.2 release lineView as Markdown

Every Nexus Atlas release ships with the evidence needed to prove, on your own machine, that the binary you hold is the binary our CI built from the tagged source — no trust in the download channel required. Any auditor with a Linux box and four open-source tools can run the whole recipe in about a minute.

What ships with every release

Artifact	What it proves
`nexus-atlasd-<ver>-<target>`	The release binary — built with an embedded, machine-readable dependency manifest (extractable with `cargo audit bin`).
`*.sha256`	Integrity: the bytes you downloaded are the bytes that were published.
`.sig` + `.pem`	Authenticity: a Sigstore/cosign keyless signature — signed by the release workflow's short-lived CI identity, so there is no long-term signing key to steal.
SLSA provenance (`*.intoto.jsonl`)	Origin: SLSA Level 3 attestation linking the artifact to the exact workflow run, commit and builder — generated in an isolated job.
`*.cdx.json`	Composition: a CycloneDX SBOM per crate, cross-checkable against the manifest embedded in the binary itself.

Behind the artifacts, CI enforces a dependency gate on every push — security advisories, yanked versions, license allowlist, registry restrictions — re-scanned weekly so a release cannot go stale quietly.

The recipe

Tools: gh, cosign, slsa-verifier, cargo-audit. Substitute the release you were granted; artifact names follow the table above.

# 0. Pick a release and target
VER=v0.2.0
TARGET=x86_64-unknown-linux-gnu
BIN=nexus-atlasd-${VER#v}-$TARGET

# 1. Get the artifacts
gh release download "$VER" -p '*'

# 2. Integrity — the checksum must hold
sha256sum -c "$BIN.sha256"

# 3. Authenticity — the keyless signature must chain to the release workflow
cosign verify-blob \
  --certificate "$BIN.pem" \
  --signature   "$BIN.sig" \
  --certificate-identity-regexp 'https://github\.com/.+/\.github/workflows/release\.yml@refs/tags/v.+' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  "$BIN"

# 4. Origin — SLSA L3 provenance must match the tag
slsa-verifier verify-artifact \
  --provenance-path "$BIN.intoto.jsonl" \
  --source-uri "$SOURCE_REPO" \
  --source-tag "$VER" \
  "$BIN"

# 5. Composition — audit the dependency manifest inside the binary itself
cargo install cargo-audit
cargo audit bin "$BIN"

Step 5 is the quiet star: the dependency manifest is embedded in the binary, so the SBOM cross-check runs against what you will actually execute, not against a sidecar file that could describe something else. The published *.cdx.json SBOMs carry the same composition for your inventory tooling.

Exact identity strings: the certificate identity and source repository for your release are stated on its download page alongside the artifacts — pin them in your own verification scripts rather than trusting this page's placeholders.

If a step fails

Checksum mismatch: stop. Re-download once; a second failure means the artifact is not what was published — contact us and do not run it.
Signature or provenance failure: stop unconditionally. There is no benign explanation for a release that fails cosign or SLSA verification.
Audit findings in step 5: read them — cargo audit reports known advisories against the embedded dependency set. Release notes state any accepted advisories and their rationale; an unexplained finding is a question for us, and we want it.

Putting it in your pipeline

The recipe is deliberately scriptable — every step exits non-zero on failure. Fleets that deploy through the Ansible role get a mandatory checksum check at delivery time as well; adding steps 3–4 to your artifact-ingestion pipeline makes "verified provenance" a property of your deploy process rather than a person's diligence.