Vérifier une release

Téléchargez les artefacts et vérifiez leurs signatures, sommes de contrôle et attestations avant l’installation. Utilisez l’identité de signature et le tag de la version téléchargée. Les exigences de réseau sont décrites ci-dessous.

Ne pipez pas un installeur dans un shell. Téléchargez les artefacts, vérifiez-les, puis exécutez-les. Les étapes ci-dessous montrent comment.

La prochaine version est la 1.0, première version stable de Community et Business/Enterprise. Elle n’est pas encore publiée. Les capacités et leurs limites actuelles sont documentées séparément. Transparence et limites.

Ce qui est livré avec une release

Une release taguée porte les archives binaires plus tout ce qui est nécessaire pour les attester :

Les attestations référencent chaque artefact par ses octets, jamais par un tag mutable.

Le chemin en une commande

Prenez scripts/verify-release.sh dans un checkout de confiance du code au tag de la version ; ce n’est pas un fichier de release. L’exécuter suppose de faire confiance à ce checkout. Utilisez son chemin depuis le répertoire des fichiers téléchargés ; il rapporte chaque étape de vérification.

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

--offline supprime la consultation de Rekor dans les appels cosign ; il ne rend pas toute la vérification indépendante du réseau. La vérification keyless nécessite les racines de confiance Sigstore, téléchargées si elles ne sont pas en cache. Le script ne propose pas d’option --trusted-root. Les bundles SBOM et OpenVEX nécessitent une racine de confiance même avec --key ; l’étape SLSA exécute slsa-verifier sans option offline. Les versions publiques sont signées keyless et ne publient pas de clé de vérification. Utilisez --key uniquement pour des fichiers signés avec une clé dont vous avez obtenu la partie publique auprès de son propriétaire par un canal distinct de celui des fichiers à vérifier.

Le script nécessite cosign et sha256sum. En mode consommateur, les attestations absentes ou l’absence de slsa-verifier sont signalées comme des étapes ignorées. Une étape ignorée n’est pas vérifiée. Le mode --strict-publication, réservé à la publication, exige aussi --cert-identity et --source-uri ; il refuse --key et --offline.

Ce qu’il vérifie, étape par étape

Si vous préférez exécuter les vérifications manuellement, voici la chaîne. Substituez <archive> avec chaque *.tar.gz.

1. Signature sur les checksums

Vérifier checksums.txt fait transitivement confiance à chaque artefact qui y est listé. La vérification keyless épingle l’identité de signature à l’identité OIDC GitHub Actions du projet :

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. Intégrité des artefacts

Recalculez le hash de chaque artefact contre le manifeste désormais de confiance :

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

3. Attestation 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. Attestation OpenVEX

La déclaration de vulnérabilité du projet, vérifiée de la même manière :

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

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

Vérifier l’image conteneur

Le chemin keyless pour l’image prouve l’image contre la même identité GitHub Actions mais nécessite un réseau. Résolvez et déployez toujours par digest, jamais par un tag mutable :

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

Dans un environnement isolé du réseau

Un opérateur crée le bundle air-gap avec une clé cosign qu’il contrôle. Le bundle inclut la clé cosign.pub correspondante ; ses scripts vérifient le chart Helm et les images sauvegardées avec cette clé, sans Rekor. Avant de faire confiance au bundle, comparez sa clé publique à une copie reçue du propriétaire par un autre canal. Une clé contenue dans le bundle n’authentifie pas ce bundle. Une image ne passe la vérification que si elle porte une signature créée avec cette clé.

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

Ce que la vérification prouve et ne prouve pas

La vérification cryptographique prouve la provenance et l’intégrité : que l’artefact est la sortie exacte et non modifiée que notre pipeline a construit et signé. Elle ne certifie pas le comportement du logiciel ni aucune posture de conformité. Olivares AI est conçu en vue de — pas certifié contre — des frameworks comme SOC 2 et ISO 27001 ; voir Transparence et limites pour ce que cette distinction signifie en pratique.

La vérification n’est aussi complète que les attestations qu’une release donnée a effectivement publiées. Le vérificateur rapporte chaque étape qu’il exécute ; si un build omet un artefact, l’étape correspondante n’a rien à vérifier. La release standard attache les artefacts SBOM, OpenVEX et SLSA nommés ci-dessus.