Vérifier une release

Olivares AI gouverne les agents de votre infrastructure, sa propre chaîne d’approvisionnement fait donc partie de votre modèle de confiance. Avant d’exécuter une release, prouvez que c’est celle que nous avons publiée. Chaque release livre les artefacts dont vous avez besoin pour le vérifier cryptographiquement — et la vérification peut se faire sans aucun réseau, ce qui est le chemin pour les environnements déconnectés et air-gappés.

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.

Statut pre-release. Aucune release publique n’a encore été publiée — olivaresai/olivares se publie avec le lancement, il n’y a donc aujourd’hui aucun artefact à télécharger ni rien contre quoi exécuter ces commandes. Ce guide documente la chaîne de vérification que portera chaque release publique ; le pipeline qui la sous-tend est construit et exercé en CI. Tout ce qui suit deviendra exécutable avec la première release taguée.

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

Le dépôt livre scripts/verify-release.sh. Exécutez-le depuis le répertoire contenant les fichiers téléchargés ; il parcourt toute la chaîne et rapporte chaque étape :

# Keyless (Sigstore) — par défaut. Nécessite un réseau vers le log de transparence (Rekor).
scripts/verify-release.sh

# Par clé — vérification contre la clé publique du projet (compatible air-gap).
scripts/verify-release.sh --key cosign.pub

# Entièrement hors ligne — par clé, aucun réseau vers le log de transparence.
scripts/verify-release.sh --key cosign.pub --offline

# Épingler la provenance SLSA à un tag source spécifique.
scripts/verify-release.sh --source-tag <version>

L’utilisation du réseau dépend du modèle de signature. Les signatures keyless portent une entrée de log de transparence Rekor, donc le chemin par défaut atteint Rekor (vous pouvez passer --offline pour utiliser une entrée embarquée à la place). Les signatures par clé sont produites sans entrée Rekor, donc le script ajoute --insecure-ignore-tlog et ne contacte rien. La combinaison --key cosign.pub --offline est le chemin véritablement déconnecté.

Le script nécessite cosign et sha256sum ; slsa-verifier est optionnel. Les étapes dont les artefacts (ou le vérificateur) sont absents sont ignorées avec une note claire plutôt qu’un échec — il fonctionne donc sur une release minimale et vérifie complètement une release complète.

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

Par clé, utilisez plutôt cosign verify-blob --key cosign.pub --signature checksums.txt.sig --insecure-ignore-tlog checksums.txt.

2. Intégrité des artefacts

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

sha256sum --check checksums.txt

3. Attestation SBOM (SPDX)

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

Ajoutez --key cosign.pub --insecure-ignore-tlog (au lieu des flags d’identité) pour le chemin hors ligne. Le SBOM CycloneDX (*.cdx.sbom.json) est livré en parallèle pour l’outillage qui le préfère.

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

Pour un environnement entièrement déconnecté, utilisez le bundle air-gap à la place : il porte l’image, ses signatures et attestations, et un cosign.pub, et se vérifie hors ligne avec cosign verify --local-image <dir> --insecure-ignore-tlog --key cosign.pub. Le guide d’auto-hébergement couvre la construction et le mirroring de ce bundle.

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 pré-1.0 et 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.