Ne nous croyez pas sur parole. Vérifiez la version.

Ce que publie chaque version

Une déclaration signée nomme le commit exact que nous déployons, son arbre de sources et chaque dépendance figée, par leurs empreintes. À côté : un SBOM qui liste chaque paquet de la version, ce que notre contrôle a vérifié (compilation, tests, analyseurs de vulnérabilités et de style), et la mesure de l’enclave qui détient les clés des agents. Les images de conteneur sont vérifiées par nos propres serveurs de production avant d’être lancées, et leurs empreintes ne sont pas publiées.

Le code qui s’exécute on-chain est publié en entier : les contrats Solidity, les registres de leurs adresses de déploiement et les cartes ERC-8004 de nos agents. Le reste du dépôt reste privé, et seules ses empreintes sont publiées. C’est un choix, et nous préférons le dire plutôt que le brouiller.

Relue par des agents autonomes, à chaque fois

Avant qu’une version soit signée, plusieurs agents IA relisent tout ce qui a changé depuis la précédente : l’un cherche comment de l’argent pourrait bouger alors qu’il ne le devrait pas, un autre les bogues ordinaires, un autre ce qui pourrait casser au déploiement, et un dernier le code on-chain quand il a changé. Un second agent, indépendant, tente ensuite de réfuter chaque constat et le marque confirmé, plausible ou rejeté.

Le script de signature refuse de signer tant qu’un constat confirmé de gravité haute n’est pas résolu, c’est-à-dire ni corrigé ni reconnu par écrit dans le dépôt. La déclaration signée porte le résumé de la relecture : les constats par gravité et le nombre de constats de gravité haute non résolus. Le rapport complet n’est pas publié, car il décrit du code privé ; son empreinte est signée, donc quiconque reçoit le rapport plus tard peut vérifier que c’est bien celui avec lequel cette version a été signée.

Ce que cela prouve : la relecture a tourné sur cette version, avec les modèles que nomme la déclaration, et a trouvé ce que son résumé compte. Ce que cela ne prouve pas : que le code n’a pas de bogue. Un modèle peut manquer des choses. C’est un élément de preuve, pas une garantie, et quiconque vous présente une relecture par IA comme une garantie vous vend quelque chose.

Un lien qui ne change pas

Chaque carte ERC-8004 de nos agents nomme cette liste comme son service « verification ». Les cartes et la chaîne restent les mêmes d’une version à l’autre ; la liste s’allonge d’une entrée à chaque fois.

Versions

La même liste, lisible par machine : https://defiloops.com/verify/releases.json

Comment vérifier une version

1. Récupérez un paquet par son CID et vérifiez la signature avec cosign, avec l’une des clés ci-dessous :

   ipfs get <cid> -o bundle && cd bundle
   cosign verify-blob --key keys/<fingerprint>.pub \
       --bundle statement.sigstore.json --insecure-ignore-tlog=true statement.json

2. Vérifiez que le SBOM est celui qui a été signé (l’empreinte doit égaler le sbom.sha256 de la déclaration), puis chaque autre fichier :

   sha256sum sbom.spdx.json
   sha256sum -c SHA256SUMS

3. Recalculez vous-même le CID du paquet. Il doit être identique à celui listé ici :

   ipfs add -r -n -Q --cid-version=0 bundle

Nos clés de version

Chaque paquet contient les clés publiques, mais un paquet ne peut pas se porter garant de lui-même : comparez leurs empreintes avec celles-ci. La première vit sur une clé matérielle et ne peut pas en être copiée ; la seconde est une sauvegarde hors ligne.

• sha256:0f94ff99b58ff464bf002bb431c575c37c81b019a7878d1c1728087ae77e6921
• sha256:392431900b5e9b16f93939b5e7098c15f41103a5e53a1c0c8e4c02b3c5824e6d