Einen Release verifizieren

Beweisen, dass ein Olivares-AI-Release der ist, den wir veröffentlicht haben — Signatur, SLSA-Provenienz, SBOM- und OpenVEX-Attestierungen verifizieren.

Olivares AI steuert die Agenten auf Ihrer Infrastruktur, daher ist seine eigene Supply Chain Teil Ihres Vertrauensmodells. Bevor Sie einen Release ausführen, beweisen Sie, dass er der ist, den wir veröffentlicht haben. Jeder Release liefert die Artefakte, die Sie brauchen, um das kryptographisch zu verifizieren — und die Verifikation kann vollständig ohne Netzwerk laufen, was der Pfad für isolierte und air-gapped Umgebungen ist.

Pipen Sie keinen Installer in eine Shell. Laden Sie die Artefakte herunter, verifizieren Sie sie, dann führen Sie sie aus. Die folgenden Schritte zeigen wie.

Pre-Release-Status. Es wurde noch kein öffentlicher Release veröffentlicht — olivaresai/olivares wird mit dem Launch veröffentlicht, sodass es heute kein Artefakt zum Herunterladen gibt und nichts, wogegen diese Befehle laufen könnten. Dieser Leitfaden dokumentiert die Verifikationskette, die jeder öffentliche Release tragen wird; die Pipeline dahinter ist gebaut und wird in CI ausgeführt. Alles Folgende wird mit dem ersten getaggten Release ausführbar.

Was mit einem Release ausgeliefert wird

Ein getaggter Release trägt die Binary-Archive plus alles, was für die Attestierung nötig ist:

Artefakt	Was es ist
`checksums.txt` (+ `.sig`, `.pem`)	SHA-256 jedes Artefakts, mit einer cosign-Signatur und (schlüssellosen) Zertifikat
`*_<os>_<arch>.tar.gz`	Die Release-Archive für linux/darwin x amd64/arm64
`.spdx.sbom.json` / `.cdx.sbom.json`	Pro-Archiv-SBOM, in SPDX- und CycloneDX-Form ausgeliefert
`*.sbom.sigstore.json`	Das SPDX-SBOM als signierte in-toto-Attestierung über das Archiv
`*.vex.sigstore.json`	Eine OpenVEX-Erklärung als signierte in-toto-Attestierung über das Archiv
`*.intoto.jsonl`	SLSA-Build-Provenienz (generiert von `slsa-github-generator`)
Container-Image	In einer Registry veröffentlicht, signiert und attestiert, per Digest gepinnt

Die Attestierungen referenzieren jedes Artefakt anhand seiner Bytes, nie anhand eines veränderlichen Tags.

Der Ein-Befehl-Pfad

Das Repository liefert scripts/verify-release.sh. Führen Sie es aus dem Verzeichnis mit den heruntergeladenen Dateien aus; es durchläuft die gesamte Kette und berichtet jeden Schritt:

# Schluessellos (Sigstore) -- Standard. Braucht Netzwerk zum Transparency Log (Rekor).
scripts/verify-release.sh

# Schluesselbasiert -- gegen den oeffentlichen Schluessel des Projekts verifizieren (air-gap-freundlich).
scripts/verify-release.sh --key cosign.pub

# Vollstaendig offline -- schluesselbasiert, ueberhaupt kein Transparency-Log-Netzwerk.
scripts/verify-release.sh --key cosign.pub --offline

# SLSA-Provenienz an einen bestimmten Quell-Tag pinnen.
scripts/verify-release.sh --source-tag <version>

Wie das Netzwerk genutzt wird, hängt vom Signaturmodell ab. Schlüssellose Signaturen tragen einen Rekor-Transparency-Log-Eintrag, sodass der Standardpfad Rekor erreicht (Sie können --offline übergeben, um stattdessen einen gebündelten Eintrag zu verwenden). Schlüsselbasierte Signaturen werden ohne Rekor-Eintrag produziert, sodass das Skript --insecure-ignore-tlog hinzufügt und nichts kontaktiert. Die Kombination --key cosign.pub --offline ist der wirklich isolierte Pfad.

Das Skript braucht cosign und sha256sum; slsa-verifier ist optional. Schritte, deren Artefakte (oder deren Verifier) fehlen, werden mit einem klaren Hinweis übersprungen, anstatt zu scheitern — sodass es mit einem minimalen Release funktioniert und einen vollständigen vollständig verifiziert.

Was es prüft, Schritt für Schritt

Wenn Sie die Prüfungen lieber von Hand ausführen, ist hier die Kette. Ersetzen Sie <archive> mit jedem *.tar.gz.

1. Signatur über die Prüfsummen

Das Verifizieren von checksums.txt vertraut transitiv jedem darin aufgeführten Artefakt. Die schlüssellose Verifikation pinnt die Signaturidentität auf die GitHub-Actions-OIDC-Identität des Projekts:

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

Schlüsselbasiert verwendet stattdessen cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.

2. Artefaktintegrität

Berechnen Sie den Hash jedes Artefakts gegen das nun vertrauenswürdige Manifest neu:

sha256sum --check checksums.txt

3. SBOM-Attestierung (SPDX)

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

Fügen Sie --key cosign.pub --insecure-ignore-tlog (anstelle der Identitäts-Flags) für den Offline-Pfad hinzu. Das CycloneDX-SBOM (*.cdx.sbom.json) wird daneben für Tools ausgeliefert, die es bevorzugen.

4. OpenVEX-Attestierung

Die Vulnerability-Erklärung des Projekts, auf dieselbe Weise verifiziert:

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

5. SLSA-Provenienz

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

Das Container-Image verifizieren

Der schlüssellose Image-Pfad beweist das Image gegen dieselbe GitHub-Actions-Identität, braucht aber Netzwerk. Lösen und deployen Sie immer per Digest, nie per veränderlichem 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

Für eine vollständig isolierte Umgebung verwenden Sie stattdessen das Air-Gap-Bundle: Es trägt das Image, seine Signaturen und Attestierungen und ein cosign.pub, und verifiziert offline mit cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. Der Self-Host-Leitfaden behandelt das Erstellen und Spiegeln dieses Bundles.

Was die Verifikation beweist und was nicht

Kryptographische Verifikation beweist Provenienz und Integrität: dass das Artefakt die exakte, unmodifizierte Ausgabe ist, die unsere Pipeline gebaut und signiert hat. Sie zertifiziert nicht das Verhalten der Software oder eine Compliance-Haltung. Olivares AI ist pre-1.0 und darauf ausgelegt — nicht zertifiziert gegen — Frameworks wie SOC 2 und ISO 27001; siehe Ehrlichkeit und Grenzen für die Bedeutung dieser Unterscheidung in der Praxis.

Die Verifikation ist auch nur so vollständig wie die Attestierungen, die ein gegebener Release tatsächlich veröffentlicht hat. Der Verifier berichtet jeden Schritt, den er ausführt; wenn ein Build ein Artefakt auslässt, hat der entsprechende Schritt nichts zu prüfen. Der Standard-Release hängt die oben genannten SBOM-, OpenVEX- und SLSA-Artefakte an.