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 termine en 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 cours d’exécution. 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 représente 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çu 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 de la chaîne d’approvisionnement logicielle font les gros titres, des packages npm compromis, des bibliothèques avec porte dérobée, des serveurs CI renégats, le processus de construction 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 du « pousser pour déployer », mais c’est le but. La sécurité n’est pas pratique.

Pour comprendre le système de construction de Bitcoin Core, nous devrions comprendre :

• La philosophie du système de construction de Bitcoin Core
• Les constructions reproductibles
• Minimiser les dépendances
• Pas de mises à jour automatiques
• Intégration continue
• 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 manière dont le logiciel lui-même est construit et distribué.

Un principe dans l’écosystème Bitcoin est « ne faites pas confiance, vérifiez ». Exécuter votre propre nœud est un acte de vérification, vérifiant chaque bloc et chaque transaction par rapport aux règles de consensus. Mais le système de construction lui-même vous donne une autre occasion de vérifier, au niveau du logiciel. Bitcoin est de l’argent sans intermédiaires de confiance et Bitcoin Core s’efforce d’être un logiciel sans constructeurs de confiance. Le système de construction prend de grandes mesures pour s’assurer que quiconque, n’importe où, peut recréer indépendamment les mêmes binaires exacts qui apparaissent sur le site web bitcoincore.org.

Cette philosophie remonte à l’essai de Ken Thompson de 1984 Reflections on Trusting Trust, qui avertissait que même un code source ayant l’air propre ne peut pas être fiable si le compilateur qui a construit ce logiciel était lui-même compromis. Les développeurs de Bitcoin ont pris cette leçon à cœur. Dans les mots du contributeur de Bitcoin Core Michael Ford (fanquake) :

« Les constructions reproductibles sont critiques, 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 monde de la sécurité, les gens parlent de « surfaces d’attaque ». Le système de construction de Bitcoin Core traite 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 tirage est examinée. Mais le voyage du code lisible par l’homme 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 étiqueté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 chaînes d’outils, des versions de compilateurs et des bibliothèques système identiques. Si tous les constructeurs produisent des sorties identiques, ils savent que la construction est déterministe.

Les contributeurs signent ensuite cryptographiquement les binaires résultants et publient ces signatures dans un dépôt GitHub séparé ‘guix.sigs’ qui répertorie 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 à quiconque du public. En fait, de nombreux contributeurs non codeurs contribuent régulièrement des signatures.

Ce processus est connu sous le nom de constructions reproductibles, et c’est l’antidote au « trust in trust » de Thompson. Cela signifie que quiconque peut prendre le code open-source, le même environnement Guix, et confirmer indépendamment que le binaire officiel correspond à ce qu’ils ont construit eux-mêmes. Bien que les constructions reproductibles puissent vérifier que le logiciel est une représentation authentique du code source du logiciel, la correction du logiciel est laissée aux processus de tests approfondis et de révision de code.

La plupart des gens ne réaliseront jamais une compilation complète ou ne vérifieront les manifests de Guix ou ne compareront les hachages 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 sorties de dizaines de constructeurs indépendants. Ce que vous téléchargez finalement est ce que tout le monde a construit et vérifié comme authentique.

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

Minimiser les dépendances : moins à faire confiance

La reproductibilité est un côté de l’équation. L’autre consiste à minimiser ce qui doit être reproduit. Le code de Bitcoin Core n’est pas le seul code exécuté lors de l’exécution de Bitcoin Core. Bitcoin Core dépend également 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. Que ce soit une bibliothèque externe ou un ensemble d’outils, ces dépendances ajoutent de la complexité ou importent des hypothèses cachées. Des projets comme Boost et Libevent, qui étaient autrefois des éléments de base de la base de code de Core, sont progressivement éliminé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 complètement. 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 « Minimiser les dépendances »[1], notant qu’il ne s’agit pas seulement d’une question de simplicité, mais de préserver la sécurité et l’autonomie du projet. Chaque dépendance supprimée est une partie externe de moins à laquelle le projet doit faire confiance 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 fonctionner, sans dépendances dynamiques ou d’exécution. Cette auto-contenance signifie aucune dépendance sur des bibliothèques externes qui pourraient différer d’un système d’exploitation à un autre.

Dans un monde où la plupart des logiciels deviennent plus lourds et plus dépendants des écosystèmes de paquets centralisés, Bitcoin Core avance 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 à laquelle ils doivent mettre à jour, ou des décisions de mettre à jour le logiciel en général. Vous installez une application, et elle se met silencieusement et automatiquement à jour vers les dernières versions en arrière-plan. Bien que cela soit pratique, c’est antithétique à la philosophie de Bitcoin Core.

Bitcoin Core n’a jamais inclus de mises à jour automatiques, et les développeurs ont déclaré qu’il n’en inclura jamais. Les mises à jour automatiques concentrent le pouvoir. Elles créent un groupe unique qui peut pousser du code (potentiellement malveillant) à chaque nœud du réseau. C’est exactement le type 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 construction et l’absence de mises à jour automatiques sont deux moitiés d’un même principe. Seul l’exécutant du nœud décide ce qu’il faut exécuter et peut vérifier que le logiciel qui est exécuté est authentique.

Intégration continue : avancer lentement et corriger les choses

Dans la Silicon Valley, l’intégration continue et le déploiement continu (CI/CD) sont les marques de fabrique du développement logiciel agile. Expédier rapidement. Itérer plus vite. Laissez 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 sauvegarder l’intégrité. Les constructions automatisées testent la cohérence à travers les plateformes. Le système de construction de Bitcoin Core est conçu pour être agnostique aux matériels et aux systèmes d’exploitation autant que possible. 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 assure cette compatibilité ainsi que l’intégrité du logiciel en effectuant 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é, non innovation continue.

Avancer lentement et corriger les choses.

Adaptation continue : avons-nous terminé ?

Le système de construction n’est pas statique. Les développeurs continuent à l’affiner en réduisant les dépendances, en améliorant les constructions inter-architectures et en explorant un avenir de constructions entièrement statiques sans dépendances d’exécution.

Bien que le système de construction de Bitcoin Core s’efforce d’atteindre le déterminisme, le système de construction lui-même ne peut pas être statique. Le monde dans lequel il opère est en constante évolution. Les systèmes d’exploitation, les compilateurs, les bibliothèques et les architectures matérielles changent tous. Chaque nouvelle version de macOS ou de glibc, chaque dépréciation d’un drapeau de compilateur, ou l’émergence d’une architecture CPU entraîne des incompatibilités subtiles qui doivent être résolues. Un système de construction qui resterait immobile finirait, avec le temps, par ne plus construire du tout.

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

Obtenez votre exemplaire de The Core Issue 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 de l’éditeur présentée dans la dernière édition imprimée de Bitcoin Magazine, The Core Issue. Nous le partageons ici comme un aperçu précoce des idées explorées tout au long du numéro complet.

[1]