398 / 736WVL

Mara van der Laan

Ancienne maintenance et publications de Bitcoin Core

Bitcoin a besoin de plus que de nouvelles idées. Il faut évaluer les modifications, préparer les versions du logiciel et transmettre les responsabilités. Mara van der Laan a assuré la maintenance de Bitcoin Core. Son travail et son départ montrent pourquoi un projet aussi important ne devrait pas dépendre d’une seule personne.

Mara van der Laan est une développeuse connue sous le compte laanwj et, dans les archives, sous le nom Wladimir van der Laan. Elle a assuré la maintenance de Bitcoin Core, un logiciel de vérification indépendante de la chaîne Bitcoin. Cette fonction impliquait une responsabilité sur le logiciel, pas une autorité sur tout le réseau.

Le profil public laanwj présente aujourd’hui Mara van der Laan et son ancienne fonction de maintenance de Bitcoin Core. Les archives emploient le nom historique Wladimir van der Laan. Il s’agit du travail de la même développeuse, pas de deux personnes différentes. Assurer la maintenance ne consiste pas seulement à inventer des fonctions. Il faut aussi juger si les changements sont prêts, coordonner leur intégration et travailler avec les personnes qui relisent et testent le code. Cette part moins visible du développement éclaire sa contribution. [1] [4]

Dans un texte du 21 janvier 2021, van der Laan décrivait un problème courant dans les projets anciens : trop de tâches finissent par dépendre d’une personne précise. Bitcoin Core comptait déjà plusieurs responsables de maintenance, mais elle souhaitait déléguer davantage et réduire son implication. Ce n’était pas l’annonce d’un arrêt complet des contributions. Il s’agissait d’éviter que les étapes importantes l’attendent personnellement. Imaginez une version prête, bloquée uniquement parce qu’une personne indispensable est indisponible. Répartir les responsabilités permet de prévenir cette situation. [2]

Le plan de 2021 concernait la distribution du logiciel, la signature des versions et les espaces de collaboration. Van der Laan envisageait IPFS pour le partage distribué de fichiers et Radicle pour travailler sur le code sans dépendre d’un serveur central. Le but était que l’indisponibilité d’une personne, d’un site ou d’un prestataire ne bloque pas les autres. Mentionner un outil atteste toutefois une proposition, pas sa mise en œuvre. Repérer une faiblesse, prévoir une solution et l’utiliser réellement sont des étapes différentes. [2]

À la réunion de développement du 11 août 2022, laanwj a annoncé son départ de la maintenance de Bitcoin Core. Concrètement, elle cesserait d’intégrer des modifications au code commun et de préparer les versions. Elle laissait ouverte la possibilité de relire occasionnellement du code : examiner les propositions d’autrui ne nécessite pas cette fonction. Elle exprimait aussi sa confiance envers les personnes qui accomplissaient déjà une grande part du travail. Les dates comptent donc : un ancien titre ne décrit pas automatiquement une fonction actuelle, et quitter celle-ci ne supprime pas toute possibilité de contribuer. [3]

Bitcoin Core décrit ses responsables de maintenance comme les personnes qui intègrent les changements relus et acceptés par l’équipe, avec une dernière vérification. Un dépôt conserve le code et son historique ; y avoir accès n’ordonne pas aux opérateurs de nœuds d’installer une version. Un nœud est un ordinateur qui vérifie les règles de Bitcoin avec le logiciel choisi. Influencer un programme important ne permet donc pas de modifier par une simple commande le comportement de tous. Séparer gestion du projet et règles adoptées par le réseau rend la décentralisation plus concrète. [4]

La responsabilité concerne aussi la personne qui télécharge Bitcoin Core. Le fichier SHA256SUMS contient les empreintes de contrôle de la version. La comparaison indique si le fichier téléchargé correspond à l’empreinte annoncée. Mais un attaquant pourrait remplacer à la fois le programme et la liste. Il faut donc aussi vérifier les signatures numériques et l’empreinte de la clé, un identifiant court de la clé publique du signataire, à comparer avec une valeur obtenue de façon fiable. Un nom inscrit sur une clé ne prouve pas l’identité. Fichier, signature et appartenance de la clé sont des vérifications liées, mais distinctes. [5]

Le code source est la forme du programme que l’on peut lire et modifier ; sa compilation produit des fichiers exécutables. Les compilations reproductibles de Bitcoin Core permettent d’obtenir indépendamment des fichiers identiques et de comparer leurs empreintes à celles de la version publiée. Cela réduit la confiance aveugle dans l’ordinateur ayant préparé le téléchargement. La concordance ne prouve toutefois pas l’absence de bogues dans le code. Une erreur peut être fidèlement reproduite dans toutes les compilations identiques. Vérifier l’origine du logiciel et examiner son code sont deux tâches complémentaires. [5]

Reste une autre question : cette version reçoit-elle encore des corrections ? Bitcoin Core publie le cycle de vie de ses versions et distingue celles qui sont maintenues de celles arrivées en fin de vie. Ces dernières ne reçoivent généralement plus de correctifs de sécurité. Une ancienne signature valide peut toujours attester l’origine du fichier initial, sans garantir sa maintenance actuelle. Vérifiez donc aussi l’état du support et les notes de version. L’histoire du projet, l’authenticité du fichier et la pertinence actuelle d’une version sont des questions différentes, quoique liées. [6]

Pour une vision complète, lisez aussi Peter Todd, Andrew Poelstra, Bitcoin Core. Cette entrée est également citée par Peter Todd, Andrew Poelstra.

DOC · 001laanwj — public developer profileDocumentation DOC · 002The widening gyre — 21 January 2021Documentation DOC · 003Bitcoin Core meeting — 11 August 2022Documentation DOC · 004Bitcoin Core — project and maintainersDocumentation DOC · 005Bitcoin Core — download verificationDocumentation DOC · 006Bitcoin Core — software life cycleDocumentation
Révisé le: Sources d’abord · Pas un conseil financier