Référence CLI

Cette référence suit continuum-attest/src/main.rs en version 0.2.0. Utilisez attest --help et attest <command> --help pour connaître les options exactes du binaire installé. Les options globales sont --verbose et --quiet.

Installation

Continuum Attest 0.2.0 prend en charge Linux et macOS, sur x86-64 et arm64, sous Apache-2.0. Consultez les fichiers de version pour les binaires et les éléments de vérification. Windows n’est pas pris en charge dans cette version.

Installer avec Cargo

Le paquet s’appelle continuum-attest sur crates.io. Installez-le avec Rust 1.89 ou ultérieur :

cargo install continuum-attest --locked

La commande installée s’appelle attest. Le paquet nommé attest appartient à un autre projet.

Premier reçu signé

Depuis le répertoire de votre projet, initialisez Continuum Attest et créez une clé de signature :

attest init
attest keys generate --name release

Adaptez le fichier attest.yaml généré pour déclarer votre commande de compilation, ses fichiers d’entrée et ses sorties. Exécutez-le, puis vérifiez le reçu avec votre espace de travail :

attest run --sign
attest verify .attest/receipts/*.yaml --recompute

La signature est explicite. Gardez les clés privées confidentielles ; le destinataire a besoin du reçu et de clés publiques approuvées indépendamment pour contrôler la signature. Recalculer les empreintes nécessite aussi les fichiers correspondants de l’espace de travail.

La spécification publique Format de reçu décrit les éléments de preuve et les règles de signature. Le Protocole de plugin est un projet de spécification ; la version 0.2.0 n’exécute aucun plugin.

Commandes

Exécuter un pipeline

attest run --pipeline attest.yaml --sign
attest run --sign --key <key-id>
attest run --check-reproducibility
attest run --sign --timestamp

--verify sélectionne l’isolation de processus : des limites de ressources, sans contrôle du réseau ni du système de fichiers. Le bloc isolation du reçu détaille les contrôles appliqués, non appliqués ou indisponibles. Cette option ne remplace pas attest verify sur le reçu obtenu. --check-reproducibility exécute deux fois le pipeline dans des espaces de travail neufs et compare les empreintes de sortie. Consultez la référence de configuration pour les champs des étapes.

Envelopper une commande

attest run --wrap --name build --input src/ --output dist/ -- npm run build

Répétez --input et --output pour plusieurs chemins. --workspace DIR choisit la racine. Le mode wrap fonctionne sans fichier de pipeline ni bac à sable. Ajoutez --sign et une clé provisionnée pour signer. Consultez l’intégration CI.

Vérifier les reçus

attest verify .attest/receipts/<receipt>.yaml
attest verify --recompute .attest/receipts/<receipt>.yaml
attest verify --trust-store /path/to/trust --format json receipt.yaml
attest verify --archive bundle.attest.tar.zst --offline
attest verify receipt.yaml --recompute --require signature,timestamp,recompute
attest verify --archive bundle.attest.tar.zst --offline --require signature,linkage,trust,success

Les codes de sortie sont 0 pour un succès, 1 pour une vérification en échec et 2 pour une erreur opérationnelle. La sortie JSON utilise NDJSON. Le contrôle des signatures est activé par défaut. --check-signatures false autorise explicitement les contrôles d’un reçu non signé et n’établit pas de confiance dans un signataire. Consultez Reçus et confiance.

Un contrôle qui n’a pas eu lieu est marqué skipped et ne satisfait jamais une exigence --require. Cette option exige un résultat ; elle n’active pas un contrôle : ajoutez --recompute pour effectuer le recalcul. Les propriétés disponibles sont signature, timestamp, recompute, linkage (archives), trust (bundle courant) et success (toutes les étapes terminées avec le code 0). Le résultat distingue la validité des preuves du succès de la compilation. Le JSON des reçus ajoute policy, execution et trust_material ; son contrat est publié dans le schéma de résultat v1.

Les archives sont limitées par défaut à 64 Mio sur disque, 512 Mio décompressées, 10 000 entrées et 64 Mio par entrée. Les reçus et enveloppes DSSE sont limités à 16 Mio avant analyse. Un dépassement produit le code 2 et le type d’erreur JSON resource-limit.

Transmettre la confiance

attest trust bundle --output trust.json --key <issuer-key-id>
attest trust show trust.json
attest trust import trust.json --issuer <issuer-key-id>
attest trust refresh trust-2.json

Le producteur signe les clés approuvées et les révocations datées dans un bundle avec une période de validité et un numéro de séquence. Le destinataire obtient l’identifiant de l’émetteur par un canal de confiance distinct avant le premier import. Une mise à jour antérieure à la séquence acceptée, un bundle altéré ou un émetteur révoqué sont refusés. La rotation d’autorité passe par un successeur désigné dans le bundle signé. L’import et l’actualisation restent explicites et hors ligne. Le verdict indique la fraîcheur du bundle selon l’horloge locale ; il ne connaît pas les révocations publiées après la dernière mise à jour.

Signer après la compilation

attest sign receipt.yaml --key <key-id> --timestamp --output signed-receipt.yaml

attest sign signe dans un processus qui n’a exécuté aucune commande du projet. ATTEST_KEYS_DIR permet de conserver les clés privées hors de l’espace de travail. Avec attest run --sign, la clé n’est chargée qu’après la sortie de la dernière étape. --timestamp et --key sans --sign sont refusés sur attest run.

Clés et empreintes

attest keys generate --name ci
attest keys list
attest keys export <key-id> --output ci.pub
attest keys import ci.pub --name team-ci
attest keys revoke <key-id>
attest keys trust-tsa digicert-ca.crt --name digicert
attest hash --input src/ --run 'npm run build'
attest hash --output dist/

L’export des clés contient uniquement les données publiques. La gestion des clés détaille le provisionnement en CI et la rotation.

Échange dans un format standard

attest export --receipt receipt.yaml --format in-toto --output statement.json
attest import statement.json --format in-toto --report json

L’export signe l’enveloppe avec une clé disponible ; --key permet de la choisir. --allow-unsigned autorise explicitement l’export non signé. L’import vérifie l’enveloppe avec le magasin de confiance ; il ne l’envoie pas vers le SaaS.

Autres groupes de commandes

attest capsule --help
attest image --help
attest causal --help

L’initialisation d’une capsule exige une référence OCI fixée par empreinte, plutôt qu’une étiquette. Son exécution nécessite un moteur de conteneurs. Évaluez ces parcours dans votre environnement avant de les adopter. Le guide développeur indique les sources et les tests associés.

Les commandes attest login, attest publish, attest deploy, attest status et attest cache ne sont pas exposées par le binaire actuel.