Verificare un rilascio

Scarica gli artefatti e verifica firme, checksum e attestazioni prima dell’installazione. Usa l’identità di firma e il tag della versione scaricata. I requisiti di rete sono descritti sotto.

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

La prossima versione è 1.0, la prima versione stabile di Community e Business/Enterprise. Non è ancora stata pubblicata. Le funzionalità e i loro limiti attuali sono documentati separatamente. Trasparenza e limiti.

Cosa viene distribuito con un rilascio

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

| Artefatto | Cos’è | |—-|—-| | checksums.txt (+ .sig, .pem) | SHA-256 di ogni artefatto, con una firma cosign e un certificato (keyless) | | *_<os>_<arch>.tar.gz | gli archivi di rilascio per linux/darwin x amd64/arm64 | | *.spdx.sbom.json | SBOM della release, in formato SPDX | | *.sbom.sigstore.json | lo SBOM SPDX come attestato in-toto firmato sull’archivio | | *.vex.sigstore.json | una dichiarazione OpenVEX come attestato in-toto firmato sull’archivio | | *.intoto.jsonl | provenienza build SLSA (generata da slsa-github-generator) | | immagine container | pubblicata su un registry, firmata e attestata, fissata per digest |

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

Il percorso a un comando

Ottieni scripts/verify-release.sh da un checkout attendibile del codice al tag della versione; non è un artefatto della release. Eseguirlo richiede fiducia in quel checkout. Usa il suo percorso dalla cartella dei file scaricati; riporta ogni passaggio di verifica.

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

--offline elimina la ricerca su Rekor dalle chiamate cosign; non rende l’intera verifica indipendente dalla rete. La verifica keyless richiede le radici di fiducia Sigstore, scaricate se non sono in cache. Lo script non ha l’opzione --trusted-root. I bundle SBOM e OpenVEX richiedono una radice di fiducia anche con --key; il passaggio SLSA esegue slsa-verifier senza opzione offline. Le versioni pubbliche sono firmate keyless e non pubblicano una chiave di verifica. Usa --key solo per file firmati con una chiave la cui parte pubblica hai ricevuto dal proprietario tramite un canale diverso da quello dei file da verificare.

Lo script richiede cosign e sha256sum. In modalità consumatore segnala come saltati i passaggi con attestazioni mancanti o senza slsa-verifier. Un passaggio saltato non è verificato. La modalità --strict-publication, riservata a chi pubblica, richiede anche --cert-identity e --source-uri; rifiuta --key e --offline.

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

2. Integrità degli artefatti

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

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

3. Attestato SBOM (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. Attestato OpenVEX

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

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. 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

In un ambiente isolato dalla rete

Un operatore crea il bundle air-gap con una chiave cosign che controlla. Il bundle include il relativo cosign.pub; gli script verificano il chart Helm e le immagini salvate con quella chiave, senza Rekor. Prima di fidarti del bundle, confronta la chiave pubblica con una copia ricevuta dal proprietario tramite un altro canale. Una chiave contenuta nel bundle non autentica il bundle stesso. Un’immagine supera la verifica solo se contiene una firma creata con quella chiave.

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

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 è 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.