REPRODUCIBLE PACKAGES ARE USELESS

SYNTHÈSE STRUCTURÉE

La promesse initiale : transformer la confiance en arithmétique

L’intervenant pose d’emblée le cadre : « Reproducibility does not make an artifact trustworthy. It makes it checkable. » Un build reproductible garantit que, pour une source et un environnement donnés, on obtient toujours les mêmes octets. L’intérêt n’est pas technique mais épistémologique : au lieu de se demander si le mainteneur est honnête, si la machine de compilation est compromise ou si le binaire a été modifié en transit, on compare deux empreintes SHA-256. La confiance n’est pas abolie, elle est déplacée vers l’acte de vérification.

La victoire technique est réelle et méritée

Le projet Reproducible Builds a éliminé pendant plus de dix ans les sources de non-déterminisme : horodatages dans les binaires, ordre aléatoire des fichiers, chemins de compilation intégrés, noms d’hôtes, numéros de processus. La normalisation de SOURCE_DATE_EPOCH a fourni un levier commun pour la cause la plus fréquente. Debian bloque désormais les paquets non reproductibles dans testing, une première historique pour une distribution généraliste. Arch, NixOS, openSUSE et Fedora publient leurs propres statistiques. L’intervenant insiste : « an enormous victory achieved by serious people, almost always volunteers, almost always unpaid. »

Le point de consommation : le point aveugle

Une fois la propriété obtenue, la question devient : qui l’exerce ? Aujourd’hui, ce sont des re-builders institutionnels (Debian, Arch, groupes académiques) qui reconstruisent en continu et publient des verdicts. Mais l’utilisateur, lui, voit un point vert et installe. L’intervenant décompose l’opération mentale : « You are receiving a claim from a party you have never audited about a computation you did not witness concerning software you’re about to execute on your own machine. » C’est exactement la même opération que lire un badge de sécurité sur un site web. Le vendeur a changé, l’opération non.

Cinq actes de foi au lieu d’un

Avant la reproductibilité, il fallait faire confiance au distributeur. Maintenant, il faut faire confiance au re-builder, à son honnêteté, à sa non-collusion avec le distributeur, à sa propre compromission, et au fait que le verdict affiché correspond à une reconstruction réelle. « Five acts of faith instead of one. » C’est une amélioration de degré, pas de nature. La conspiration à deux est plus difficile qu’un mensonge à un, mais on consomme toujours une affirmation.

L’indépendance est un fait social, pas technique

L’indépendance d’un re-builder n’est pas visible dans un graphique. Les personnes capables de faire tourner une infrastructure de re-vérification sont souvent les mêmes qui maintiennent les paquets : mêmes conférences, mêmes financements, mêmes administrations. « It is simply social mechanics. » La formule des deux parties indépendantes est solide sur le papier, mais bien plus molle en pratique.

Le coût exclut structurellement l’utilisateur

Devenir un vérificateur indépendant exige des serveurs, des outils spécifiques à chaque distribution, la compréhension de la reconstruction des environnements, et un engagement opérationnel continu. Ces coûts sélectionnent automatiquement les institutions. L’utilisateur individuel, pourtant le plus intéressé, est exclu « structurally, not out of malice, by architecture. »

Les six étapes concrètes pour vérifier un seul paquet

L’intervenant détaille le parcours réel :

1. Trouver la recette exacte (dépôt, commit, disposition).
2. Reconstruire l’environnement de build (versions des dépendances, disponibilité des paquets historiques).
3. Récupérer les paramètres de compilation (flags, options de durcissement, base temporelle), souvent implicites dans la configuration générale de la distribution.
4. Faire fonctionner le système de build de la distribution, avec ses conventions et ses modes d’échec.
5. Comparer les empreintes — « the only easy step ».
6. Publier le résultat — et là, il n’y a nulle part où le mettre.

Cinq de ces six étapes sont du travail d’infrastructure, aucune n’est intellectuellement intéressante, et toutes sont automatisables par le distributeur, qui connaissait déjà les réponses au moment du build.

L’information jetée par le distributeur

« Every single obstacle standing in front of you is information that somebody had and chose not to publish in a form a program could consume. » Le distributeur savait tout au moment de la compilation : versions exactes, flags, environnement. Il a choisi de ne pas le publier dans un format consommable par une machine. C’est le cœur du problème.

La vérification privée ne change rien

Une vérification dont le résultat reste privé ne modifie qu’une seule confiance personnelle. Sans registre public, signé, durable, une divergence n’est pas une preuve mais une rumeur. L’intervenant est cinglant : « It is some guy on a forum saying the hashes don’t match. » Pour qu’une vérification ait un effet systémique, le résultat doit être publiable, attribuable à une clé, et permanent.

Guix et Nix : la reproductibilité par construction

Les gestionnaires de paquets fonctionnels obtiennent la reproductibilité par définition : l’environnement de build fait partie de l’identité du résultat, il est dans le hash lui-même. Pas besoin de reconstruire après coup. guix challenge compare ce que vous avez construit localement avec ce que les serveurs de substituts fournissent, et signale les divergences. guix time machine reconstruit un environnement passé exactement. L’intervenant qualifie guix challenge de « most conceptually honest interface that exists anywhere in the ecosystem today. »

Le bootstrap : le problème de Ken Thompson

Le problème le plus radical n’est pas la reproductibilité mais le compilateur initial. Un compilateur malveillant peut insérer une backdoor dans le compilateur qu’il génère, et cette backdoor peut se reproduire elle-même. Lire tout le code source ne suffit pas. Guix a réduit le binaire initial opaque à quelques centaines de kilo-octets, puis à moins, une graine inspectable à la main par un humain, à partir de laquelle toute la chaîne d’outils est reconstruite. « The most profoundly honest work done in free software in the last 15 years. »

Le nouveau pourcentage à mesurer

La question actuelle — combien de paquets sont reproductibles ? — est presque réglée. La question suivante est différente : combien de personnes autres que le distributeur ont vérifié quelque chose ce mois-ci ? Combien de clés distinctes ont signé une attestation ? Combien de tentatives de vérification ont été menées à terme ? Une tentative abandonnée est un coût encore trop élevé. « An ecosystem verifiable by everyone is not an ecosystem with more green builds. It is an ecosystem where the act of verifying is within reach of somebody who does not compile packages for a living. »

CONCEPTS CLÉS

• Build reproductible : propriété d’un système de compilation qui, pour une source et un environnement déclarés identiques, produit toujours des octets identiques, bit pour bit.
• SOURCE_DATE_EPOCH : variable d’environnement standardisée pour fixer la date de référence lors d’un build, éliminant la principale source de non-déterminisme (les horodatages).
• Re-builder institutionnel : infrastructure opérée par un tiers (Debian, Arch, groupe académique) qui reconstruit les paquets et publie des verdicts de reproductibilité.
• guix challenge : outil de Guix qui compare les résultats de builds locaux avec ceux des serveurs de substituts, signalant les divergences.
• guix time machine : outil de Guix qui reconstruit un environnement passé exactement, avec les versions précises des dépendances.
• Bootstrap : processus de construction de la chaîne d’outils à partir d’un binaire initial minimal, réduit par Guix à quelques centaines de kilo-octets inspectables à la main.
• Attestation signée : résultat de vérification publié, signé avec une clé cryptographique, et enregistré dans un registre public durable.

CONCLUSION

La reproductibilité des builds est une victoire technique indiscutable, mais elle a échoué à tenir sa promesse épistémologique : libérer l’utilisateur de la confiance. En pratique, elle a remplacé une confiance unique par une confiance multiple, plus raffinée mais toujours aussi aveugle. Le problème n’est pas la malveillance mais le coût : vérifier un paquet exige une infrastructure que seules les institutions peuvent supporter. La solution ne consiste pas à atteindre 100 % de paquets reproductibles, mais à rendre l’acte de vérification accessible à tous, avec un résultat publiable, signé et permanent. « The original promise was that you would not have to take anybody’s word for it. And a status page is somebody’s word for it. »