Skip to content

Guides

Verify a release

Verify release signatures, checksums and attestations, with the current network and trust-root requirements.

Last updated:

Download the release artifacts and verify their signatures, checksums and attestations before installation. Use the signing identity and tag of the release you downloaded. Verification has network requirements described below.

Do not pipe an installer into a shell. Download the artifacts, verify them, then run them. The steps below are how.

The next release is 1.0, the first stable release of Community and Business/Enterprise. It is not yet released. Capabilities and their current limits are documented separately. Honesty & limits.

What ships with a release

A tagged release carries the binary archives plus everything needed to attest them:

ArtifactWhat it is
checksums.txt (+ .sig, .pem)SHA-256 of every artifact, with a cosign signature and (keyless) certificate
*_<os>_<arch>.tar.gzthe release archive(s) for linux/darwin × amd64/arm64
*.spdx.sbom.jsonSBOM of the release, in SPDX form
*.sbom.sigstore.jsonthe SPDX SBOM wrapped as a signed in-toto attestation over the archive
*.vex.sigstore.jsonan OpenVEX statement as a signed in-toto attestation over the archive
*.intoto.jsonlSLSA build provenance (generated by slsa-github-generator)
container imagepublished to a registry, signed and attested, pinned by digest

The attestations reference each artifact by its bytes, never by a mutable tag.

The one-command path

Obtain scripts/verify-release.sh from a trusted source checkout of the release tag; it is not a release asset. Running it trusts that checkout. Use its path below from the directory containing the downloaded files; it reports each verification step.

/path/to/olivares/scripts/verify-release.sh --source-tag <version>

--offline removes the Rekor lookup from the cosign calls; it does not make the whole verification network-free. Keyless verification needs Sigstore trusted-root material, fetched unless it is cached. The script has no --trusted-root option. SBOM and OpenVEX bundle checks need a trusted root even with --key; the SLSA step runs slsa-verifier without an offline option. Public releases are signed keyless and do not publish a verification key. Use --key only for files signed with a key whose public part you obtained from its owner through a channel separate from the files you verify.

The script requires cosign and sha256sum. In consumer mode it reports missing attestations or a missing slsa-verifier as skipped steps. A skipped step is unverified. The publisher-only --strict-publication mode also requires --cert-identity and --source-uri; it rejects --key and --offline.

What it checks, step by step

If you prefer to run the checks by hand, this is the chain. Substitute <archive> with each *.tar.gz.

1. Signature over the checksums

Verifying checksums.txt transitively trusts every artifact listed in it. Keyless verification pins the signing identity to the project’s GitHub Actions OIDC identity:

cosign verify-blob \
  --certificate checksums.txt.pem \
  --signature checksums.txt.sig \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  checksums.txt

2. Artifact integrity

Re-compute every artifact’s hash against the now-trusted manifest:

sha256sum --ignore-missing --check checksums.txt

3. SBOM attestation (SPDX)

cosign verify-blob-attestation --type spdxjson \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --bundle <archive>.sbom.sigstore.json --new-bundle-format \
  --check-claims <archive>

4. OpenVEX attestation

The project’s vulnerability statement, verified the same way:

cosign verify-blob-attestation --type openvex \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --bundle <archive>.vex.sigstore.json --new-bundle-format \
  --check-claims <archive>

5. SLSA provenance

slsa-verifier verify-artifact <archive> \
  --provenance-path <provenance>.intoto.jsonl \
  --source-uri github.com/olivaresai/olivares

Verifying the container image

The keyless image path proves the image against the same GitHub Actions identity but needs network. Always resolve and deploy by digest, never by a mutable tag:

IMAGE=ghcr.io/olivaresai/olivares
DIGEST="$(crane digest "$IMAGE:<version>")"
REF="$IMAGE@$DIGEST"

cosign verify "$REF" \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v?[0-9]+\.[0-9]+(\.[0-9]+)?$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

In an air-gapped environment

An operator builds the air-gap bundle with a cosign key they control. The bundle includes the matching cosign.pub; its scripts check the Helm chart and saved images against that key without Rekor. Before trusting the bundle, compare its public key with a copy obtained from the key owner through a separate channel. A key inside a bundle does not authenticate the bundle it came with. An image passes only if it carries a signature made with that key.

for d in images/*/; do
  cosign verify --local-image "$d" --insecure-ignore-tlog --key cosign.pub
done
cosign verify-blob --key cosign.pub --insecure-ignore-tlog --signature chart/*.tgz.sig chart/*.tgz

What verification does and does not prove

Cryptographic verification proves provenance and integrity: that the artifact is the exact, unmodified output our pipeline built and signed. It does not certify the software’s behavior or any compliance posture. Olivares AI is designed toward — not certified against — frameworks like SOC 2 and ISO 27001; see Honesty & limits for what that distinction means in practice.

Verification is also only as complete as the attestations a given release actually published. The verifier reports each step it runs; if a build omits an artifact, the corresponding step has nothing to check. The standard release attaches the SBOM, OpenVEX and SLSA artifacts named above.

Search documentation