Verificare un rilascio

Dimostrare che un rilascio Olivares AI e quello che abbiamo pubblicato — verificare la firma, la provenienza SLSA, gli attestati SBOM e OpenVEX.

Olivares AI governa gli agenti sulla tua infrastruttura, quindi la sua supply chain fa parte del tuo modello di fiducia. Prima di eseguire un rilascio, dimostra che è quello che abbiamo pubblicato. Ogni rilascio include gli artefatti necessari per verificarlo crittograficamente — e la verifica può avvenire senza alcuna rete, che è il percorso per estate disconnessi e air-gapped.

Non inviare un installer a una shell tramite pipe. Scarica gli artefatti, verificali, poi eseguili. I passaggi sotto indicano come.

Stato pre-rilascio. Non è ancora stato pubblicato alcun rilascio pubblico — olivaresai/olivares viene pubblicato con il lancio, quindi oggi non c’è alcun artefatto da scaricare né nulla su cui eseguire questi comandi. Questa guida documenta la catena di verifica che accompagnerà ogni rilascio pubblico; la pipeline che la sostiene è costruita e viene esercitata in CI. Tutto ciò che segue diventerà eseguibile con il primo rilascio taggato.

Cosa viene distribuito con un rilascio

Un rilascio taggato include gli archivi del binario più tutto il necessario per attestarli:

Gli attestati fanno riferimento a ogni artefatto per i suoi byte, mai per un tag mutabile.

Il percorso a un comando

Il repository distribuisce scripts/verify-release.sh. Eseguilo dalla directory contenente i file scaricati; percorre l’intera catena e riporta ogni passaggio:

# Keyless (Sigstore) — default. Needs network to the transparency log (Rekor).
scripts/verify-release.sh

# Key-based — verify against the project's public key (air-gap friendly).
scripts/verify-release.sh --key cosign.pub

# Fully offline — key-based, no transparency-log network at all.
scripts/verify-release.sh --key cosign.pub --offline

# Pin SLSA provenance to a specific source tag.
scripts/verify-release.sh --source-tag <version>

Come viene usata la rete dipende dal modello di firma. Le firme keyless portano una voce nel transparency log di Rekor, quindi il percorso predefinito raggiunge Rekor (puoi passare --offline per usare una voce incorporata). Le firme basate su chiave vengono prodotte senza una voce Rekor, quindi lo script aggiunge --insecure-ignore-tlog e non contatta nulla. La combinazione --key cosign.pub --offline e il percorso genuinamente disconnesso.

Lo script richiede cosign e sha256sum; slsa-verifier e opzionale. I passaggi i cui artefatti (o il cui verificatore) sono assenti vengono saltati con una nota chiara anziché fallire — cosi funziona su un rilascio minimale e verifica completamente uno completo.

Cosa verifica, passo per passo

Se preferisci eseguire i controlli a mano, questa è la catena. Sostituisci <archive> con ogni *.tar.gz.

1. Firma sul file dei checksum

Verificare checksums.txt conferma transitivamente ogni artefatto elencato. La verifica keyless fissa l’identità di firma all’identità OIDC di GitHub Actions del progetto:

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

La verifica basata su chiave usa invece cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.

2. Integrità degli artefatti

Ricalcola l’hash di ogni artefatto rispetto al manifesto ora attendibile:

sha256sum --check checksums.txt

3. Attestato SBOM (SPDX)

cosign verify-blob-attestation --type spdxjson \
  --bundle <archive>.sbom.sigstore.json --new-bundle-format \
  --check-claims <archive>

Aggiungi --key cosign.pub --insecure-ignore-tlog (al posto dei flag di identità) per il percorso offline. Lo SBOM CycloneDX (*.cdx.sbom.json) viene distribuito a fianco per gli strumenti che lo preferiscono.

4. Attestato OpenVEX

La dichiarazione sulle vulnerabilita del progetto, verificata allo stesso modo:

cosign verify-blob-attestation --type openvex \
  --bundle <archive>.vex.sigstore.json --new-bundle-format \
  --check-claims <archive>

5. Provenienza SLSA

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

Verificare l’immagine container

Il percorso keyless per l’immagine dimostra l’immagine rispetto alla stessa identità GitHub Actions ma necessita di rete. Risolvi e distribuisci sempre per digest, mai per un tag mutabile:

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

Per un estate completamente disconnesso, usa invece il bundle air-gap: include l’immagine, le sue firme e attestati, e un cosign.pub, e verifica offline con cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. La guida self-host copre la costruzione e il mirroring di quel bundle.

Cosa la verifica dimostra e cosa no

La verifica crittografica dimostra provenienza e integrità: che l’artefatto e l’output esatto e non modificato che la nostra pipeline ha costruito e firmato. Non certifica il comportamento del software ne alcuna postura di conformita. Olivares AI e pre-1.0 ed è progettato verso — non certificato rispetto a — framework come SOC 2 e ISO 27001; vedi Trasparenza e limiti per cosa significa quella distinzione in pratica.

La verifica e anche completa solo quanto gli attestati che un dato rilascio ha effettivamente pubblicato. Il verificatore riporta ogni passaggio che esegue; se una build omette un artefatto, il passaggio corrispondente non ha nulla da verificare. Il rilascio standard allega gli artefatti SBOM, OpenVEX e SLSA nominati sopra.