Een release verifiëren

Download de release-artefacten en controleer vóór installatie hun handtekeningen, checksums en attestaties. Gebruik de ondertekeningsidentiteit en tag van de gedownloade versie. De netwerkeisen staan hieronder.

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

De volgende versie is 1.0, de eerste stabiele versie van Community en Business/Enterprise. Deze is nog niet uitgebracht. De functies en hun huidige grenzen zijn apart gedocumenteerd. Eerlijkheid & beperkingen.

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

Haal scripts/verify-release.sh uit een vertrouwde broncode-checkout van de releasetag; het is geen releasebestand. Door het uit te voeren vertrouwt u die checkout. Gebruik het pad vanuit de map met gedownloade bestanden; het rapporteert elke verificatiestap.

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

--offline verwijdert de Rekor-opvraag uit cosign-aanroepen; de volledige verificatie wordt daarmee niet netwerkvrij. Sleutelloze verificatie heeft vertrouwde Sigstore-roots nodig, die zonder cache worden gedownload. Het script heeft geen optie --trusted-root. SBOM- en OpenVEX-bundels hebben ook met --key een vertrouwde root nodig; de SLSA-stap voert slsa-verifier zonder offline-optie uit. Publieke releases worden sleutelloos ondertekend en publiceren geen verificatiesleutel. Gebruik --key alleen voor bestanden waarvan u de publieke ondertekeningssleutel van de eigenaar heeft ontvangen via een ander kanaal dan de te verifiëren bestanden.

Het script vereist cosign en sha256sum. In consumentenmodus meldt het ontbrekende attestaties of een ontbrekende slsa-verifier als overgeslagen stappen. Een overgeslagen stap is niet geverifieerd. De modus --strict-publication, alleen voor uitgevers, vereist ook --cert-identity en --source-uri; deze weigert --key en --offline.

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

2. Artefactintegriteit

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

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

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

De kwetsbaarheidsverklaring van het project, op dezelfde manier geverifieerd:

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

In een van het netwerk afgesloten omgeving

Een beheerder maakt de air-gap-bundel met een cosign-sleutel die hij beheert. De bundel bevat de bijbehorende cosign.pub; de scripts controleren de Helm-chart en opgeslagen images met die sleutel zonder Rekor. Vergelijk de publieke sleutel voordat u de bundel vertrouwt met een kopie die u via een ander kanaal van de eigenaar heeft ontvangen. Een sleutel in een bundel authenticeert die bundel zelf niet. Een image slaagt alleen als het een handtekening met die sleutel bevat.

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

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 ontworpen richting — niet gecertificeerd tegen — frameworks zoals SOC 2 en ISO 27001; zie Eerlijkheid & 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.