CE QUE FAIT LE NOYAU
L'ARTEFACT SIGNÉ PRODUIT
LA LIAISON — POURQUOI CE REÇU NE PEUT PAS MENTIR
Le ticket d'autorisation et le reçu d'exécution portent les mêmes empreintes. L'action exécutée est donc, prouvablement, celle qui a été autorisée — contre l'état exact qui avait été examiné. Ces valeurs viennent d'une exécution réelle.
Ce que cette démonstration ne prouve pas
Le dossier d'assurance produit par cette exécution porte sept revendications. Six sont satisfaites. Une ne l'est pas, et la page l'affiche plutôt que de la masquer :
- effect_attested_by_independent_observer — non satisfaite. L'effet est rapporté par l'exécuteur, pas attesté par un observateur séparé. Le labo durci ajoute cet observateur ; cette démonstration ne l'a pas.
- Aucun système réel n'est touché. La cible est synthétique, dans un simulateur SQLite local.
- Aucun audit indépendant. Le dépôt n'a pas été évalué par un tiers, et ne doit recevoir aucune identification de production.
- Le reçu du journal n'est pas au format standard. La capsule est une enveloppe SCITT conforme, relue par une bibliothèque COSE tierce ; le reçu d'inclusion, lui, est un format AEGIS dans une enveloppe COSE, pas le format IETF cose-merkle-tree-proofs. Il porte son propre type pour qu'on ne puisse pas le confondre.
- Aucune provenance de build. Ce reçu vient d'un poste de développement, sans release derrière lui ; la page le dit plutôt que d'afficher une valeur qui ressemblerait à une preuve. Une release publiée porte l'empreinte de son SBOM dans chaque reçu.
- Huit risques résiduels sont énumérés par le dossier lui-même — dont : les connexions coupées pendant la quarantaine ne sont pas rétablies, et les données déjà exfiltrées ne sont pas récupérables.