Laden Sie die Release-Artefakte herunter und prüfen Sie vor der Installation Signaturen, Prüfsummen und Attestierungen. Verwenden Sie die Signaturidentität und den Tag der heruntergeladenen Version. Die Netzwerkanforderungen stehen unten.
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.
Die nächste Version ist 1.0, die erste stabile Version von Community und Business/Enterprise. Sie ist noch nicht veröffentlicht. Funktionen und ihre aktuellen Grenzen sind separat dokumentiert. Ehrlichkeit und Grenzen.
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 | SBOM des Releases im SPDX-Format |
*.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
Beziehen Sie scripts/verify-release.sh aus einem vertrauenswürdigen Quellcode-Checkout des Release-Tags; es ist kein Release-Artefakt. Die Ausführung vertraut diesem Checkout. Rufen Sie es über seinen Pfad aus dem Verzeichnis der heruntergeladenen Dateien auf; es meldet jeden Prüfschritt.
/path/to/olivares/scripts/verify-release.sh --source-tag <version>--offline entfernt die Rekor-Abfrage aus den cosign-Aufrufen; die gesamte Prüfung wird dadurch nicht netzwerkfrei. Die schlüssellose Prüfung benötigt Sigstore-Vertrauensanker, die ohne Cache heruntergeladen werden. Das Skript hat keine Option --trusted-root. SBOM- und OpenVEX-Bundle-Prüfungen benötigen auch mit --key einen Vertrauensanker; der SLSA-Schritt führt slsa-verifier ohne Offline-Option aus. Öffentliche Releases werden schlüssellos signiert und veröffentlichen keinen Prüfschlüssel. Verwenden Sie --key nur für Dateien, deren öffentlichen Signaturschlüssel Sie vom Eigentümer über einen anderen Kanal als die zu prüfenden Dateien erhalten haben.
Das Skript benötigt cosign und sha256sum. Im Verbrauchermodus werden fehlende Attestierungen oder ein fehlender slsa-verifier als übersprungene Schritte gemeldet. Übersprungene Schritte sind ungeprüft. Der nur für Herausgeber bestimmte Modus --strict-publication benötigt auch --cert-identity und --source-uri; er lehnt --key und --offline ab.
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.txt2. Artefaktintegrität
Berechnen Sie den Hash jedes Artefakts gegen das nun vertrauenswürdige Manifest neu:
sha256sum --ignore-missing --check checksums.txt3. SBOM-Attestierung (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-Attestierung
Die Vulnerability-Erklärung des Projekts, auf dieselbe Weise verifiziert:
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-Provenienz
slsa-verifier verify-artifact <archive> \
--provenance-path <provenance>.intoto.jsonl \
--source-uri github.com/olivaresai/olivaresDas 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.comIn einer vom Netz getrennten Umgebung
Ein Betreiber erstellt das Air-Gap-Bundle mit einem eigenen cosign-Schlüssel. Das Bundle enthält den passenden cosign.pub; seine Skripte prüfen den Helm-Chart und gespeicherte Images mit diesem Schlüssel ohne Rekor. Vergleichen Sie den öffentlichen Schlüssel vor dem Vertrauen in das Bundle mit einer Kopie, die Sie vom Schlüsseleigentümer über einen separaten Kanal erhalten haben. Ein Schlüssel im Bundle authentifiziert das Bundle selbst nicht. Ein Image besteht die Prüfung nur mit einer Signatur dieses Schlüssels.
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/*.tgzWas 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 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.