Le 2025-08-03, SSP Wallet v1.25.0 a livré deux changements qui, ensemble, corrigent l'une des plus anciennes faiblesses tues de la distribution de portefeuilles : il n'est plus nécessaire de croire que le binaire du store est celui du dépôt. Les versions sont désormais compilées de manière déterministe dans Docker et signées avec GPG. N'importe qui — pas seulement nous, pas seulement un auditeur — peut recompiler depuis les sources et vérifier que ce qu'il obtient correspond, octet pour octet, à ce que nous avons publié.
Don't trust, verify — appliqué aux binaires de wallet
La maxime bitcoin « ne fais pas confiance, vérifie » concerne d'habitude les transactions. Elle s'applique, avec la même force, au logiciel qui les signe. Le code d'un portefeuille peut être ouvert et audité et néanmoins livrer un binaire compromis, parce que le chemin du code au binaire passe par un serveur de build, une étape de packaging, une clé de signature et un upload au store. Chaque maillon peut être empoisonné. Un jeton CI fuité, un binaire échangé dans le pipeline, un agent de build trafiqué — rien de tout cela ne touche le dépôt public et rien n'est visible depuis un git log.
La réponse défensive à ce modèle de menace est que le binaire lui-même doit être vérifiable. Pas « vérifiable parce qu'on le promet ». Reproductible par des inconnus.
Builds déterministes avec Docker
C'est ce que v1.25.0 livre. Chaque version SSP est désormais compilée dans un conteneur Docker avec une image de base figée, des versions de toolchain figées et un environnement complètement isolé. La build n'a pas d'accès réseau là où elle n'en a pas besoin, ne laisse pas fuiter le système de fichiers de l'hôte, n'inscrit pas d'horodatages dans la sortie ni de chemins spécifiques à la machine. La sortie est une fonction déterministe des entrées.
La conséquence pratique : un code source identique produit des binaires identiques avec des sommes de contrôle identiques. Prends le tag, compile-le dans le conteneur documenté sur ta machine et tu obtiendras le même SHA-256 que nous. Sinon, quelque chose a divergé entre le tag et le binaire publié — et c'est précisément le signal souhaité, parce que le seul résultat honnête est « le binaire correspond au code » ou « il ne correspond pas ».
C'est la mitigation contre les attaques de chaîne d'approvisionnement. Elle ne suppose pas que le serveur de build est honnête. Elle ne suppose pas que le portable du développeur est propre. Elle ne suppose rien et donne à des inconnus les outils pour vérifier.
Versions signées avec GPG
La reproductibilité dit qu'un binaire correspond à un arbre de sources. Elle ne dit pas, à elle seule, quel arbre est le vrai. C'est ce que la signature GPG résout.
Chaque artefact de v1.25.0 — les bundles de l'extension, le fichier de checksums — est signé avec la clé de release SSP. La signature est publiée à côté de la release sur GitHub. Pour vérifier un téléchargement, tu importes la clé publique une fois, tu exécutes gpg --verify sur la signature et l'outil te dit si le fichier est intact et si la clé qui a signé est bien celle attendue.
Les deux mécanismes se composent. La signature GPG prouve « c'est le fichier que SSP a publié ». La build déterministe prouve « ce fichier correspond à ce commit ». Ensemble ils suppriment l'espace de confiance entre commit et installation.
Comment vérifier une release toi-même
La page de la release sur GitHub est la source faisant autorité pour les étapes exactes — empreinte de la clé publique, noms des fichiers de signature, commande Docker pour reproduire une build. Version courte : importe la clé de release SSP, télécharge le fichier de checksums et sa signature, exécute gpg --verify sur la signature, puis sha256sum -c les checksums contre le binaire téléchargé. Si les deux passent, l'artefact est intact et authentique.
Les utilisateurs avancés qui veulent aller plus loin peuvent cloner le tag, lancer la build Docker documentée et confirmer que le SHA-256 résultant correspond au checksum publié. La plupart ne le feront jamais. Le point est que certains le feront, et qu'un seul d'entre eux trouvant un écart révèle une attaque immédiatement.
Ce que ça change
SSP est open source depuis v1.0.0 et audité par Halborn de bout en bout depuis l'examen complet publié début 2025. v1.25.0 ferme le troisième côté de ce triangle. Open source veut dire que tu peux lire le code ; audité veut dire que des experts l'ont examiné ; reproductible plus signé veut dire que ce qui tourne sur ta machine est bel et bien le code que tu as lu.
Les trois garanties sont indépendantes et se composent. Un binaire open-source non reproductible peut encore cacher une compromission dans le pipeline de build. Un projet audité non reproductible peut encore livrer un binaire trafiqué que les auditeurs n'ont jamais vu. Avec v1.25.0, « vérifie avant d'installer » cesse d'être une aspiration et devient une liste concrète.
C'est l'histoire de chaîne d'approvisionnement d'un portefeuille auto-custodial, racontée comme seule manière honnête de la raconter.