Publier et vérifier la preuve du journal

Glass Ocean 0.4.0 ajoute un point de référence enregistré indépendamment à une livraison. Publiez un engagement lié à la racine causale du reçu signé, conservez la preuve d’inclusion du journal et livrez-la avec le logiciel. Le destinataire la vérifie hors ligne avec une clé de journal qu’il a approuvée indépendamment.

Choisir un journal avant de publier

Vous choisissez et configurez l’opérateur. Attest n’exploite pas de service public de journalisation. Le premier adaptateur prend en charge un point d’écriture brut compatible Tessera, les lectures C2SP tlog-tiles et les points de contrôle signed-note Ed25519.

Obtenez les adresses, l’origine du point de contrôle et la clé de vérification par votre canal de confiance. Configuration du producteur :

{
  "format": "attest-log/v1",
  "origin": "<OPERATOR_CHECKPOINT_ORIGIN>",
  "verifier_key": "<NAME+KEY_ID+BASE64_NOTE_VERIFIER_KEY>",
  "read_url": "https://<LOG_READ_ENDPOINT>/",
  "submit_url": "https://<LOG_WRITE_ENDPOINT>/add"
}

HTTPS est obligatoire et les redirections sont refusées. Un fichier tls_ca facultatif ajoute votre autorité interne ; les chemins relatifs se résolvent à côté de la configuration. Ce profil ne prend pas d’identifiants d’API de journal : aucun jeton dans les URL ou les dépôts. Le destinataire n’a besoin que de format, origin et verifier_key, fournis indépendamment de l’expéditeur.

Examiner les informations divulguées

La publication est irréversible. L’entrée contient un engagement aléatoire renouvelé, sans la racine causale, le code source, les artefacts ni les logs du build. L’opérateur voit néanmoins l’adresse de connexion, le moment et les en-têtes des requêtes ; les observateurs voient les entrées, leur ordre et les nouvelles tentatives. Le paquet de preuve conserve l’ouverture permettant au destinataire d’associer l’entrée au reçu. Consultez le contrat de divulgation versionné avant d’activer cette fonction.

Produire, publier et livrer

Exécuter un build ne publie jamais d’entrée à lui seul. Créez un reçu signé, puis passez son chemin exact à la publication et à l’empaquetage :

attest run --wrap --name build --input src/ --output dist/ --sign -- make dist
attest causal publish --receipt <EXACT_RECEIPT_PATH> \
  --log-config producer-log.json --output publication.json \
  --publication-policy required --timeout-secs 30 --format json
attest evidence pack <EXACT_RECEIPT_PATH> --workspace . \
  --publication publication.json --output release.attest.tar.zst

Configurez d’abord une clé de signature comme indiqué dans la référence CLI. La publication exige un reçu signé et approuvé contenant une racine causale. Un ancien reçu sans racine nécessite un nouveau build. Fournissez les manifestes de capsule référencés lors de l’empaquetage si le build utilise des capsules.

Conservez publication.json. Attest enregistre durablement son intention avant la soumission ; répéter la commande avec le même fichier reprend la même entrée. Un enregistrement confirmé est revérifié sans nouvelle soumission. Au plus trois tentatives de soumission sont conservées par enregistrement. Ne lancez pas de publications concurrentes sur un même enregistrement.

Seule une inclusion vérifiée sous un point de contrôle authentifié donne confirmed. Un index retourné ne suffit pas. Avec required, l’absence de confirmation renvoie 3 ; avec optional, elle renvoie 0 et conserve un enregistrement unconfirmed et sa raison. Les erreurs locales renvoient 2. Une expiration peut signifier une acceptation sans confirmation. Le délai explicite va de 1 à 120 secondes, avec requêtes et tentatives bornées.

Vérifier hors ligne chez le destinataire

Transmettez l’archive par un canal adapté à son contenu. Configurez la confiance dans les reçus et dans le journal indépendamment :

attest evidence verify release.attest.tar.zst \
  --trust-store recipient-trust/ --log-trust recipient-log.json \
  --require signature,success,artifacts,capsule,linkage,log-inclusion --format json

Un enregistrement non confirmé ne satisfait pas log-inclusion. Sans confiance dans le journal, le contrôle est ignoré ; l’archive ne fournit jamais sa propre autorité. Une signature invalide, une entrée modifiée ou un chemin invalide échoue. Le destinataire peut exiger la publication même si le producteur l’a traitée comme facultative.

Comparer des observations obtenues indépendamment

Conservez un point de contrôle signé obtenu indépendamment de cette livraison. Récupérer la preuve de comparaison est une opération réseau explicite ; transférez les points de contrôle signés et la preuve au destinataire hors ligne :

attest causal fetch-consistency --first-checkpoint observed.note \
  --second-checkpoint publication.note --log-config producer-log.json \
  --output comparison.json
attest evidence verify release.attest.tar.zst \
  --trust-store recipient-trust/ --log-trust recipient-log.json \
  --log-checkpoint observed.note --log-consistency comparison.json \
  --require log-inclusion,log-consistency --format json

La note signée exacte de la livraison se trouve dans l’enregistrement confirmé à outcome.checkpoint. Des racines authentifiées différentes à taille égale prouvent un conflit. Deux tailles non vides différentes nécessitent un chemin de cohérence valide. Une comparaison manquante est ignorée et ne satisfait pas log-consistency. Une comparaison réussie couvre ces observations, sans garantir la vue de tous les observateurs, une exécution correcte du build ni une date de build authentifiée.

Activer depuis GitHub ou GitLab CI

Utilisez l’intégration et le binaire 0.4, avec le guide d’adoption CI versionné. log-publication-policy vaut off par défaut. Choisissez explicitement required ou optional avec log-config ; log-timeout-secs fixe le délai. Une adresse sans politique explicite est refusée avant le build.

Après un build signé réussi, la publication dans le journal précède l’empaquetage. Un build en échec conserve son code de sortie et ne publie pas d’entrée. log-publication-status, log-publication-reason et log-publication-record décrivent cette opération séparément de publication-status, qui décrit le dépôt des artefacts CI. Une publication obligatoire échoue avec le code 3 même si le dépôt des preuves est facultatif ; une publication facultative non confirmée conserve sa raison dans le paquet de preuve et le rapport de statut.

Mettez les destinataires à jour en 0.4 avant d’envoyer des paquets contenant des preuves de journal. Ils utilisent attest-evidence/v3 ; sans enregistrement de publication, les paquets restent en v2. Les paquets v1/v2 existants et les signatures des anciens reçus restent vérifiables.