Een release verifiëren

Olivares AI bestuurt de agents op je infrastructuur, dus de eigen toeleveringsketen is onderdeel van je vertrouwensmodel. Voordat je een release draait, bewijs dat het degene is die wij hebben gepubliceerd. Elke release levert de artefacten die je nodig hebt om dat cryptografisch te verifiëren — en de verificatie kan volledig zonder netwerk draaien, wat het pad is voor ontkoppelde en air-gapped domeinen.

Pipe geen installer in een shell. Download de artefacten, verifieer ze, en draai ze dan. De stappen hieronder zijn hoe.

Pre-release-status. Er is nog geen publieke release gepubliceerd — olivaresai/olivares gaat live met de lancering, dus vandaag is er geen artefact om te downloaden en niets om deze commando’s tegen te draaien. Deze gids documenteert de verificatieketen die elke publieke release zal meedragen; de pipeline erachter is gebouwd en wordt in CI beproefd. Alles hieronder wordt uitvoerbaar met de eerste getagde release.

Wat er met een release meekomt

Een getagde release bevat de binary-archieven plus alles wat nodig is om ze te attesteren:

De attestaties refereren elk artefact op zijn bytes, nooit op een muteerbare tag.

Het one-command pad

De repository levert scripts/verify-release.sh. Draai het vanuit de directory met de gedownloade bestanden; het doorloopt de hele keten en rapporteert elke stap:

# Sleutelloos (Sigstore) — standaard. Heeft netwerk nodig naar het transparantielog (Rekor).
scripts/verify-release.sh

# Sleutelgebaseerd — verifieer tegen de publieke sleutel van het project (air-gap-vriendelijk).
scripts/verify-release.sh --key cosign.pub

# Volledig offline — sleutelgebaseerd, helemaal geen transparantielog-netwerk.
scripts/verify-release.sh --key cosign.pub --offline

# Pin SLSA-herkomst op een specifieke brontag.
scripts/verify-release.sh --source-tag <version>

Hoe het netwerk wordt gebruikt hangt af van het ondertekeningsmodel. Sleutelloze handtekeningen bevatten een Rekor-transparantielog-entry, dus het standaardpad bereikt Rekor (je kunt --offline doorgeven om in plaats daarvan een gebundelde entry te gebruiken). Sleutelgebaseerde handtekeningen worden geproduceerd zonder Rekor-entry, dus het script voegt --insecure-ignore-tlog toe en contacteert niets. De --key cosign.pub --offline combinatie is het echt ontkoppelde pad.

Het script vereist cosign en sha256sum; slsa-verifier is optioneel. Stappen waarvan de artefacten (of verifier) ontbreken worden overgeslagen met een duidelijke melding in plaats van te falen — zodat het werkt op een minimale release en volledig verifieert op een complete.

Wat het controleert, stap voor stap

Als je de controles liever handmatig uitvoert, is dit de keten. Vervang <archive> met elk *.tar.gz.

1. Handtekening over de checksums

Het verifiëren van checksums.txt vertrouwt transitief elk artefact dat erin is opgenomen. Sleutelloze verificatie pinnet de ondertekeningsidentiteit op de GitHub Actions OIDC-identiteit van het project:

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

Sleutelgebaseerd gebruikt in plaats daarvan cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.

2. Artefactintegriteit

Herbereken elke hash van elk artefact tegen het nu-vertrouwde manifest:

sha256sum --check checksums.txt

3. SBOM-attestatie (SPDX)

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

Voeg --key cosign.pub --insecure-ignore-tlog toe (in plaats van de identiteitsvlaggen) voor het offline pad. De CycloneDX SBOM (*.cdx.sbom.json) wordt ernaast geleverd voor tooling die de voorkeur geeft.

4. OpenVEX-attestatie

De kwetsbaarheidsverklaring van het project, op dezelfde manier geverifieerd:

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

5. SLSA-herkomst

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

Het containerimage verifiëren

Het sleutelloze imagepad bewijst het image tegen dezelfde GitHub Actions-identiteit maar heeft netwerk nodig. Los altijd op en deploy op digest, nooit op een muteerbare 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

Voor een volledig ontkoppeld domein, gebruik in plaats daarvan de air-gap-bundel: het bevat het image, zijn handtekeningen en attestaties, en een cosign.pub, en verifieert offline met cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. De zelfhostgids behandelt het bouwen en spiegelen van die bundel.

Wat verificatie wel en niet bewijst

Cryptografische verificatie bewijst herkomst en integriteit: dat het artefact de exacte, ongewijzigde uitvoer is die onze pipeline heeft gebouwd en ondertekend. Het certificeert niet het gedrag van de software of enige compliancestatus. Olivares AI is pre-1.0 en is ontworpen richting — niet gecertificeerd tegen — frameworks zoals SOC 2 en ISO 27001; zie Eerlijkheid en beperkingen voor wat dat onderscheid in de praktijk betekent.

Verificatie is ook slechts zo compleet als de attestaties die een gegeven release daadwerkelijk heeft gepubliceerd. De verifier rapporteert elke stap die het uitvoert; als een build een artefact weglaat, heeft de corresponderende stap niets om te controleren. De standaard release bevat de SBOM-, OpenVEX- en SLSA-artefacten die hierboven zijn genoemd.