Le problème central : Au-delà du binaire, vérifier la confiance

Lorsque la plupart des gens téléchargent Bitcoin Core, leur interaction avec le système de construction se limite à quelques clics. Ils récupèrent le binaire exécutable du logiciel, vérifient une signature (espérons-le !), et commencent à faire fonctionner un nœud Bitcoin. Ce qu’ils voient immédiatement, c’est un logiciel en fonctionnement. Ce qu’ils ne voient pas, c’est le système de construction et les processus étendus qui ont produit ce logiciel. Un système de construction qui incarne les principes de décentralisation, de transparence et de vérifiabilité de Bitcoin.

Derrière ce téléchargement se cache des années de travail d’ingénierie conçues pour répondre à une question simple : « Pourquoi quelqu’un devrait-il faire confiance à ce logiciel ? » La réponse est : il ne devrait pas avoir à le faire. Il doit pouvoir le vérifier.

À une époque où les attaques contre la chaîne d’approvisionnement logicielle font la une des journaux mondiaux, des paquets npm compromis, des bibliothèques backdoordées, des serveurs CI malveillants, le processus de construction de Bitcoin Core se présente comme un projet discret de discipline. Ses méthodes peuvent sembler lentes et compliquées comparées à la commodité sans friction du « push to deploy », mais c’est le but. La sécurité n’est pas pratique.

Pour comprendre le système de construction de Bitcoin Core, il faut d’abord comprendre :

• La philosophie du système de construction de Bitcoin Core
• Les constructions reproductibles
• La minimisation des dépendances
• L’absence de mises à jour automatiques
• L’intégration continue
• L’adaptation continue

La philosophie du système de construction de Bitcoin Core

En ce qui concerne la décentralisation de Bitcoin, la plupart des gens se concentrent sur les mineurs, les nœuds et les développeurs. Mais la décentralisation ne s’arrête pas aux participants du protocole. Elle s’étend à la façon dont le logiciel lui-même est construit et distribué.

Un principe dans l’écosystème Bitcoin est « ne pas faire confiance, vérifier ». Faire fonctionner son propre nœud est un acte de vérification, contrôlant chaque bloc et transaction selon les règles de consensus. Mais le système de construction lui-même offre une autre opportunité de vérification, au niveau logiciel. Bitcoin est une monnaie sans intermédiaires de confiance, et Bitcoin Core vise à être un logiciel sans constructeurs de confiance. Le système de construction prend de grandes précautions pour garantir que quiconque, n’importe où, peut recréer indépendamment les mêmes binaires qui apparaissent sur le site bitcoincore.org.

Cette philosophie remonte à l’essai de Ken Thompson de 1984, Reflections on Trusting Trust, qui mettait en garde contre le fait qu’un code source apparemment propre ne peut pas être digne de confiance si le compilateur qui a construit ce logiciel a été compromis lui-même. Les développeurs de Bitcoin ont retenu cette leçon. Selon Michael Ford (fanquake), contributeur à Bitcoin Core :

« Les constructions reproductibles sont essentielles, car aucun utilisateur de notre logiciel ne devrait avoir à faire confiance à ce qui est contenu à l’intérieur. Cela doit toujours être vérifiable de manière indépendante. »

Une déclaration qui est à la fois un objectif technique et une partie de l’éthique de Bitcoin.

Dans le domaine de la sécurité, on parle de « surfaces d’attaque ». Le système de construction de Bitcoin Core considère le processus de construction lui-même comme une surface d’attaque à minimiser et à défendre.

Constructions reproductibles : Vérification jusqu’au bout

Le processus de production d’une version de Bitcoin Core commence avec la base de code open-source sur GitHub. Chaque changement est public. Chaque demande de fusion est revue. Mais le chemin de la code lisible par l’humain au logiciel binaire exécutable implique des compilateurs, des bibliothèques tierces, et des systèmes d’exploitation qui sont eux-mêmes des vecteurs potentiels de manipulation, de portes dérobées ou d’erreurs.

« Les tiers de confiance sont des failles de sécurité » – Nick Szabo (2001)

Pour répondre à ces préoccupations, Bitcoin Core a conçu un pipeline de processus de construction utilisant Guix, un gestionnaire de paquets conçu pour créer des environnements logiciels reproductibles et déterministes.

Lorsqu’une nouvelle version de Bitcoin Core est taguée, plusieurs contributeurs indépendants construisent les binaires à partir de zéro en utilisant Guix. Chaque constructeur travaille dans un environnement isolé garantissant des chaînes d’outils, des versions de compilateur et des bibliothèques système identiques. Si tous produisent des sorties identiques, ils savent que la construction est déterministe.

Les contributeurs signent cryptographiquement les binaires résultants et publient ces signatures dans un dépôt GitHub séparé, ‘guix.sigs’, qui liste ces attestations pour chaque version de Bitcoin Core. Certains constructeurs sont des développeurs de Bitcoin Core, mais ce n’est pas une exigence, car le processus d’attestation est ouvert à tous. En fait, de nombreux contributeurs non liés au code contribuent régulièrement avec des signatures.

Ce processus, appelé constructions reproductibles, est l’antidote à la « confiance aveugle » de Thompson. Il permet à quiconque de prendre le code source open-source, le même environnement Guix, et de confirmer indépendamment que le binaire officiel correspond à ce qu’il a lui-même construit. Bien que ces constructions reproductibles puissent vérifier que le logiciel est une représentation authentique de son code source, la correction du logiciel repose sur des processus de tests approfondis et de revue de code.

La plupart des gens ne réaliseront jamais une compilation complète ni ne vérifieront les manifestes Guix ou ne compareront les hashs de construction. Ils n’en ont pas besoin. L’existence de cette infrastructure, et des personnes qui la maintiennent, donne à chaque utilisateur une base de confiance acquise.

Les binaires officiels sur bitcoincore.org ne sont pas simplement « produits par les mainteneurs de Bitcoin Core ». Ils représentent l’intersection des résultats de dizaines de constructeurs indépendants. Ce que vous téléchargez finalement, c’est ce que tout le monde a construit et vérifié comme étant authentique.

C’est la vérification jusqu’au bout.

Minimiser les dépendances : Moins de choses à faire confiance

La reproductibilité est une facette de l’équation. L’autre est de minimiser ce qui doit être reproduit. Le code de Bitcoin Core n’est pas le seul code exécuté lors de l’utilisation de Bitcoin Core. Il dépend aussi de code et de bibliothèques tierces externes pour accélérer le développement et la productivité.

Au cours de la dernière décennie, les développeurs de Bitcoin Core ont progressivement éliminé ces dépendances tierces inutiles et parfois problématiques, comme OpenSSL et MiniUPnP. Qu’il s’agisse d’une bibliothèque ou d’un outil externe, ces dépendances ajoutent de la complexité ou introduisent des hypothèses cachées. Des projets comme Boost et Libevent, autrefois piliers du code de Core, sont progressivement abandonnés ou remplacés par des alternatives plus simples et autonomes.

Pourquoi ? Parce que chaque dépendance que vous héritez est un risque potentiel pour la chaîne d’approvisionnement. C’est plus de code que vous n’avez pas écrit, que vous n’auditez pas, et que vous ne pouvez pas contrôler entièrement. Réduire les dépendances rend le système de construction plus léger, plus sûr et plus facile à vérifier.

Brink a récemment souligné cet effort dans son article de blog « Minimizing Dependencies[1] », en notant que ce n’est pas seulement une question de simplicité, mais aussi de préserver la sécurité et l’autonomie du projet. Chaque dépendance supprimée est une partie externe en moins à faire confiance, et une porte dérobée potentielle en moins.

L’objectif final est de produire des binaires entièrement statiques : des exécutables contenant tout ce dont ils ont besoin pour fonctionner, sans dépendances dynamiques ou d’exécution. Cette autosuffisance signifie qu’il n’y a pas besoin de bibliothèques externes pouvant différer d’un système d’exploitation à un autre.

Dans un monde où la majorité des logiciels devient plus lourd et dépend davantage des écosystèmes de paquets centralisés, Bitcoin Core va dans la direction opposée : vers le minimalisme et l’indépendance.

Pas de mises à jour automatiques

Dans la plupart des logiciels modernes, les utilisateurs sont protégés des décisions concernant la version du logiciel à mettre à jour ou de la mise à jour elle-même. Vous installez une application, et elle se met à jour silencieusement et automatiquement en arrière-plan vers la dernière version. Bien que pratique, cela va à l’encontre de la philosophie de Bitcoin Core.

Bitcoin Core n’a jamais inclus de mises à jour automatiques, et ses développeurs ont déclaré qu’il ne le fera jamais. Les mises à jour automatiques concentrent le pouvoir. Elles créent un groupe unique pouvant pousser (potentiellement malveillant) du code vers tous les nœuds du réseau. C’est précisément ce que Bitcoin cherche à éviter. En obligeant les utilisateurs à télécharger, vérifier et installer manuellement les nouvelles versions, Bitcoin Core renforce la responsabilité individuelle et le consentement vérifiable.

Le système de construction et l’absence de mises à jour automatiques sont deux aspects d’un même principe. Seul le gestionnaire du nœud décide de ce qu’il exécute et peut vérifier que le logiciel utilisé est authentique.

Intégration continue : Avancer lentement et corriger

Dans la Silicon Valley, l’intégration continue et le déploiement continu (CI/CD) sont les marques d’un développement logiciel agile. Livrer rapidement. Itérer plus vite. Laisser l’automatisation faire le reste.

Bitcoin Core adopte une approche différente. Ses systèmes CI existent non pas pour accélérer le déploiement, mais pour garantir l’intégrité. Les constructions automatisées testent la cohérence entre plateformes. Le système de construction de Bitcoin Core est conçu pour être aussi indépendant que possible du matériel et des systèmes d’exploitation. Le projet peut construire des binaires pour Linux, macOS, Windows, ainsi que pour plusieurs architectures comme x86_64, aarch64 (ARM), et même riscv64. Le système d’intégration continue assure cette compatibilité ainsi que l’intégrité du logiciel en effectuant des centaines de tests pour chaque modification proposée.

Le résultat est une culture où « l’intégration continue » signifie tests continus, vérification et sécurité, pas innovation continue.

Avancer lentement et corriger.

Adaptation continue : Sommes-nous arrivés au bout ?

Le système de construction n’est pas statique. Les développeurs continuent de l’affiner en réduisant les dépendances, en améliorant la construction multi-architecture, et en explorant un avenir de construction entièrement statique avec zéro dépendance d’exécution.

Bien que le système de construction de Bitcoin Core vise le déterminisme, il ne peut pas être statique lui-même. Le monde dans lequel il évolue change constamment. Systèmes d’exploitation, compilateurs, bibliothèques et architectures matérielles évoluent tous. Chaque nouvelle version de macOS ou glibc, chaque dépréciation d’un drapeau de compilateur, ou architecture CPU émergente introduit des incompatibilités subtiles qu’il faut traiter. Un système de construction qui resterait immobile finirait par ne plus pouvoir construire du tout avec le temps.

Le paradoxe des constructions reproductibles est qu’elles nécessitent une évolution continue pour rester reproductibles. Les développeurs doivent constamment fixer, patcher, et parfois remplacer les chaînes d’outils pour préserver le déterminisme face à un environnement en mouvement. Maintenir cet équilibre entre stabilité et adaptabilité fait partie de la résilience continue de Bitcoin.

Obtenez votre exemplaire de The Core Issue dès aujourd’hui !

Ne manquez pas votre chance de posséder The Core Issue — avec des articles écrits par de nombreux développeurs de Bitcoin Core expliquant eux-mêmes leurs projets !

Ce texte est la Lettre de l’Éditeur publiée dans la dernière édition imprimée de Bitcoin Magazine, The Core Issue. Nous le partageons ici en avant-première pour donner un aperçu des idées explorées dans tout le numéro.

[1]