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

Quand la plupart des gens téléchargent Bitcoin Core, leur interaction avec le système de build se termine en quelques clics. Ils récupèrent le binaire exécutable du logiciel, vérifient une signature (espérons-le !), puis commencent à exécuter un nœud Bitcoin. Ce qu’ils voient immédiatement, c’est un logiciel en cours d’exécution. Ce qu’ils ne voient pas, c’est le système de build et les processus approfondis qui ont produit ce logiciel. Un système de build qui reflète les principes de Bitcoin en matière de décentralisation, de transparence et de vérifiabilité.

Derrière ce téléchargement se cachent 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 : vous ne devriez pas avoir à le faire. Vous devriez pouvoir vérifier.

À une époque où les attaques contre la chaîne d’approvisionnement des logiciels font la une des journaux à l’échelle mondiale, depuis des packages npm compromis jusqu’à des bibliothèques implantant des portes dérobées, en passant par des serveurs CI pirates, le processus de build de Bitcoin Core se présente comme un projet silencieux de discipline. Ses méthodes peuvent sembler lentes et compliquées par rapport à la commodité sans friction de « pousser pour déployer », mais c’est justement le point. La sécurité n’est pas pratique.

Pour comprendre le système de build de Bitcoin Core, il faut comprendre :

• La philosophie du système de build de Bitcoin Core
• Les builds reproductibles
• Réduire au minimum les dépendances
• Pas de mises à jour automatiques
• L’intégration continue
• Adaptation continue

Philosophie du système de build 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 manière dont le logiciel lui-même est construit et distribué.

Un principe de l’écosystème Bitcoin est « ne faites pas confiance, vérifiez ». Exécuter votre propre nœud est un acte de vérification, consistant à contrôler chaque bloc et chaque transaction par rapport aux règles de consensus. Mais le système de build lui-même vous offre une autre opportunité de vérifier, au niveau logiciel. Bitcoin est de l’argent sans intermédiaires de confiance, et Bitcoin Core vise à être un logiciel sans créateurs de confiance. Le système de build déploie de grands efforts pour que quiconque, n’importe où, puisse recréer de manière indépendante exactement les mêmes binaires que ceux qui apparaissent sur le site bitcoincore.org.

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

« Les builds reproductibles sont essentielles, parce qu’aucun utilisateur de notre logiciel ne devrait avoir à faire confiance à ce qui est contenu en son sein pour affirmer que c’est bien ce que nous disons. Cela doit toujours pouvoir être vérifié de manière indépendante. »

Une déclaration à la fois objectif technique et partie de l’éthos Bitcoin.

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

Builds reproductibles : la vérification jusque dans les détails

Le processus de production d’une publication de Bitcoin Core commence par la base de code open source sur GitHub. Chaque modification est publique. Chaque demande d’intégration (pull request) est examinée. Mais le parcours du code lisible par les humains vers le 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 sabotage, 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 inquiétudes, l’architecte de Bitcoin Core a mis en place une chaîne de processus de build avec 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 étiquetée (taguée), plusieurs contributeurs indépendants construisent les binaires à partir de zéro en utilisant Guix. Chaque constructeur travaille dans un environnement isolé qui garantit des toolchains identiques, des versions de compilateur identiques et des bibliothèques système identiques. Si tous les constructeurs produisent des sorties strictement identiques au bit près, ils savent alors que le build est déterministe.

Les contributeurs signent ensuite cryptographiquement les binaires obtenus et publient ces signatures sur un dépôt GitHub distinct, « guix.sigs », qui liste ces attestations pour chaque publication de Bitcoin Core. Certains constructeurs sont des développeurs de Bitcoin Core, mais ce n’est pas une exigence : le processus d’attestation est ouvert à quiconque dans le public. En fait, de nombreux contributeurs qui ne participent pas au code fournissent régulièrement des signatures.

Ce processus est connu sous le nom de builds reproductibles, et il constitue l’antidote au « fait de faire confiance » de Thompson. Cela signifie que chacun peut prendre le code open source, le même environnement Guix, et confirmer de manière indépendante que le binaire officiel correspond à ce qu’il a construit lui-même. Bien que les builds reproductibles puissent vérifier que le logiciel est bien une représentation authentique du code source du logiciel, la correction du logiciel repose sur des processus impliquant des tests approfondis et la revue de code.

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

Les binaires officiels sur bitcoincore.org ne sont pas seulement « produits par les mainteneurs de Bitcoin Core ». Ce sont le point de rencontre des sorties 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 jusque dans les détails.

Réduire au minimum les dépendances : moins de choses à faire confiance

La reproductibilité est un des côtés de l’équation. L’autre est de réduire au minimum ce qu’il faut reproduire. Le code de Bitcoin Core n’est pas le seul code exécuté lors du lancement de Bitcoin Core. Bitcoin Core s’appuie aussi sur du code et des bibliothèques externes, fournis par des tiers, pour accélérer le développement et améliorer la productivité.

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

Pourquoi ? Parce que chaque dépendance que vous héritez représente un risque potentiel pour la chaîne d’approvisionnement. C’est plus de code que vous n’avez pas écrit, que vous n’aurez pas audité, et sur lequel vous ne pouvez pas avoir un contrôle total. Réduire les dépendances rend le système de build plus léger, plus sûr et plus facile à vérifier.

Récemment, Brink a mis en avant cet effort dans son billet « Minimizing Dependencies » [1], notant qu’il ne s’agit pas seulement de simplicité, mais aussi de préserver la sécurité et l’autonomie du projet. Chaque dépendance supprimée correspond à une entité externe en moins que le projet doit devoir croire, et à un potentiel de porte dérobée en moins.

L’objectif final est de produire des binaires entièrement statiques : des exécutables qui contiennent tout ce dont ils ont besoin pour s’exécuter, sans dépendances dynamiques ni dépendances d’exécution. Cette auto-contenance signifie qu’il n’y a pas de dépendance à des bibliothèques externes qui pourraient différer d’un système d’exploitation à l’autre.

Dans un monde où la plupart des logiciels deviennent plus lourds et dépendent davantage d’écosystèmes de paquets centralisés, Bitcoin Core se dirige 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 relatives à la version de logiciel à laquelle mettre à jour, ou même de la décision de mettre à jour le logiciel du tout. Vous installez une application, et elle se met silencieusement et automatiquement à jour vers les dernières versions en arrière-plan. Même si c’est pratique, c’est contraire à la philosophie de Bitcoin Core.

Bitcoin Core n’a jamais inclus de mises à jour automatiques, et les développeurs ont dit que ce ne sera jamais le cas. Les mises à jour automatiques concentrent le pouvoir. Elles créent un groupe unique qui peut pousser (potentiellement malveillant) du code vers chaque nœud du réseau. C’est exactement le genre de contrôle centralisé que Bitcoin a été conçu pour éviter. En exigeant que les utilisateurs téléchargent, vérifient et installent manuellement de nouvelles versions, Bitcoin Core renforce la responsabilité individuelle et le consentement vérifiable.

Le système de build et l’absence de mises à jour automatiques constituent deux moitiés du même principe. Seul l’exécuteur de nœud décide quoi exécuter, et peut vérifier que le logiciel exécuté 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 signatures distinctives du développement logiciel agile. Livrer vite. Itérer encore plus vite. L’automatisation s’occupe du reste.

Bitcoin Core adopte une approche différente. Ses systèmes CI existent non pas pour accélérer le déploiement, mais pour sauvegarder l’intégrité. Les builds automatisés testent la cohérence entre les plateformes. Le système de build 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 et Windows ainsi que pour plusieurs architectures, y compris x86_64, aarch64 (ARM) et même riscv64. Le système d’intégration continue garantit cette compatibilité ainsi que l’intégrité du logiciel en exécutant des centaines de tests pour chaque changement proposé.

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

Avancer lentement et corriger.

Adaptation continue : en a-t-on fini ?

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

Bien que le système de build de Bitcoin Core s’efforce d’être déterministe, le système de build lui-même ne peut pas être statique. Le monde dans lequel il opère est en perpétuel mouvement. Les systèmes d’exploitation, les compilateurs, les bibliothèques et les architectures matérielles changent tous. Chaque nouvelle publication de macOS ou de glibc, chaque dépréciation d’une option (flag) de compilateur, ou chaque architecture CPU émergente introduit des incompatibilités subtiles qui doivent être traitées. Un système de build qui resterait immobile finirait, avec le temps, par ne plus pouvoir être construit du tout.

Le paradoxe des builds reproductibles est qu’ils nécessitent une évolution continue pour rester reproductibles. Les développeurs doivent constamment figer (pin), corriger (patch), et parfois remplacer les toolchains afin de préserver le déterminisme dans un contexte de changements perpétuels. 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 Core expliquant les projets sur lesquels ils travaillent eux-mêmes !

Ce texte est la Lettre du Rédacteur en chef présentée dans le dernier numéro Print de Bitcoin Magazine, The Core Issue. Nous la partageons ici comme un premier aperçu des idées explorées tout au long du numéro complet.

[1]