Vérification des artefacts de release
ZeroClaw utilise les attestations d’artefacts GitHub comme mécanisme de provenance canonique pour les ressources de version téléchargeables. Chaque attestation réussie enregistre l’empreinte de la ressource, le commit source et l’identité du workflow de version en tant que provenance SLSA v1.0 Build Level 2.
L’attestation prouve où et comment un artefact a été généré. Elle ne prouve pas qu’un humain a examiné le code source, que les dépendances sont sûres, ni qu’un compte de mainteneur, un exécuteur hébergé par GitHub ou le plan de contrôle GitHub n’a pas été compromis. Consultez docs/security/slsa-provenance.md dans le dépôt pour connaître le modèle complet des menaces.
Le workflow de publication traite actuellement les attestations comme une sortie de phase A au titre du meilleur effort. Consultez les notes de version avant de vous fier au matériel de vérification ; elles indiquent si la provenance en ligne et l’archive hors ligne ont été produites.
Vérification en ligne
Installez le GitHub CLI, téléchargez une ressource et vérifiez-la par rapport au workflow de publication et au commit source :
VERSION=vX.Y.Z
SOURCE_DIGEST=<40-character-release-commit>
ASSET=zeroclaw-x86_64-unknown-linux-gnu.tar.gz
gh release download "$VERSION" --repo zeroclaw-labs/zeroclaw \
--pattern "$ASSET"
gh attestation verify "$ASSET" \
--repo zeroclaw-labs/zeroclaw \
--signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
--source-digest "$SOURCE_DIGEST"
Utilisez le commit complet indiqué pour le tag de version. Une commande réussie affiche l’attestation vérifiée et le condensé du sujet. La même commande s’applique à install.sh, SHA256SUMS, aux deux fichiers SBOM et à l’archive de vérification.
Vérification hors ligne
Une version produite par le workflow consolidé avec la sortie complète de la Phase A publie une archive nommée zeroclaw-vX.Y.Z-verification.tar.gz. Elle contient :
- un bundle
<artifact>.attestation.jsonlpour chaque charge utile de version ; trusted_root.jsonl, le matériel de racine de confiance GitHub et Sigstore ;ATTESTATION-BUNDLES.md, un index des noms d’artefacts, des empreintes SHA-256 et des noms de bundles.
L’archive ne peut pas contenir sa propre attestation sans créer un condensat circulaire. Établissez la chaîne de confiance initiale en étant connecté en vérifiant l’archive et le fichier de somme de contrôle final en ligne. Transférez ensuite l’artefact, l’archive et le fichier de somme de contrôle dans l’environnement hors ligne.
Étape de préparation connectée
VERSION=vX.Y.Z
SOURCE_DIGEST=<40-character-release-commit>
ASSET=zeroclaw-x86_64-unknown-linux-gnu.tar.gz
VERIFY_ARCHIVE="zeroclaw-${VERSION}-verification.tar.gz"
gh release download "$VERSION" --repo zeroclaw-labs/zeroclaw \
--pattern "$ASSET" \
--pattern SHA256SUMS \
--pattern "$VERIFY_ARCHIVE"
gh attestation verify "$VERIFY_ARCHIVE" \
--repo zeroclaw-labs/zeroclaw \
--signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
--source-digest "$SOURCE_DIGEST"
gh attestation verify SHA256SUMS \
--repo zeroclaw-labs/zeroclaw \
--signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
--source-digest "$SOURCE_DIGEST"
awk -v file="$VERIFY_ARCHIVE" '$2 == file { print }' SHA256SUMS | sha256sum -c -
mkdir verification
tar -xzf "$VERIFY_ARCHIVE" -C verification
Comparez également l’empreinte de l’artefact avec sa ligne dans SHA256SUMS avant le transfert :
awk -v file="$ASSET" '$2 == file { print }' SHA256SUMS | sha256sum -c -
Étape de vérification déconnectée
Aucune requête réseau n’est nécessaire lorsque --bundle et --custom-trusted-root pointent tous deux vers le matériel de vérification préparé :
gh attestation verify "$ASSET" \
--repo zeroclaw-labs/zeroclaw \
--signer-workflow zeroclaw-labs/zeroclaw/.github/workflows/release-stable-manual.yml \
--source-digest "$SOURCE_DIGEST" \
--bundle "verification/${ASSET}.attestation.jsonl" \
--custom-trusted-root verification/trusted_root.jsonl
SHA256SUMS et l’archive de vérification sont des métadonnées d’amorçage en ligne et ne contiennent pas de bundles dans l’archive. Toutes les charges utiles présentes avant la construction de l’archive, notamment install.sh et les deux SBOM, en ont.
SBOMs
Deux fichiers SBOM checksummés et attestés sont publiés à chaque version :
| Fichier | Format |
|---|---|
zeroclaw-vX.Y.Z-sbom.spdx.json | SPDX JSON |
zeroclaw-vX.Y.Z-sbom.cdx.json | CycloneDX JSON |
Vérifiez l’un ou l’autre SBOM avec la même commande d’attestation en ligne ou hors ligne utilisée pour un actif binaire. Des outils tels que Syft ou Grype peuvent ensuite inspecter le fichier vérifié.
Images de conteneur
Les images de conteneurs GHCR restent signées par digest avec cosign. Cela est indépendant du processus d’attestation GitHub pour les artefacts de version téléchargeables.
IMAGE=ghcr.io/zeroclaw-labs/zeroclaw
TAG=vX.Y.Z
cosign verify \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
--certificate-identity-regexp "^https://github.com/zeroclaw-labs/zeroclaw/" \
"${IMAGE}:${TAG}"
Pour les déploiements épinglés, résolvez le condensé et vérifiez ${IMAGE}@${DIGEST} plutôt qu’un tag mutable.