The Truth About Debian's Reproducible Packages Source Code Ep. 20

SYNTHÈSE STRUCTURÉE

Qu’est-ce qu’une compilation reproductible ?

Une compilation est reproductible lorsque, à partir du même code source et des mêmes conditions de compilation, on obtient un binaire identique bit pour bit, quel que soit l’exécutant, la machine ou le moment. L’intervenant insiste : « Ça semble évident, ça ne l’est pas. » Une compilation normale est truffée de non-déterminismes cachés : timestamps embarqués, ordre des fichiers dans le système de fichiers, parallélisme de compilation, chemins absolus, locale, identifiant de processus, aléas des optimisations, versions des dépendances. Le projet Reproducible Builds travaille depuis dix ans à colmater ces brèches une par une.

Les huit sources principales de non-déterminisme

L’intervenant énumère huit causes typiques qui rendent deux compilations du même code différentes :

Timestamps embarqués : macros C comme __DATE__ ou __TIME__, dates de modification dans les archives, dates de build.
Ordre du système de fichiers : le linker reçoit les fichiers dans un ordre non garanti, ce qui change les adresses des symboles.
Parallélisme de compilation : compiler avec 8 threads produit un ordre d’assemblage différent qu’avec 16.
Chemins absolus : le compilateur inscrit le chemin du fichier source dans le binaire.
Langue et fuseau horaire : l’ordre des chaînes, les dates dans la documentation, la sortie de certains outils changent.
Identifiant de processus, nom de machine, nombre de CPU : ces données finissent dans les journaux de build, parfois embarqués dans les paquets.
Aléas réels : identifiants de build aléatoires, offsets mémoire stockés.
Versions exactes des dépendances de build : un en-tête système légèrement différent, un compilateur patché par la distribution, et le binaire change.

Le rôle de la variable `SOURCE_DATE_EPOCH`

Pour normaliser la date de build, le projet Reproducible Builds a standardisé la variable d’environnement SOURCE_DATE_EPOCH. Les chaînes d’outils modernes (compilateurs, archiveurs) l’honorent pour figer la date de compilation. L’intervenant précise que cela a permis de corriger tar pour qu’il trie les fichiers par nom et neutralise leur date de modification, et de pousser les compilateurs Rust et Go à rendre par défaut l’option qui supprime les chemins absolus.

Ce que la reproductibilité ne garantit PAS

L’intervenant est très clair : « Les paquets reproductibles ne servent pas à vérifier que le binaire correspond à la source. » Il détaille trois angles morts majeurs :

Attaque « Trusting Trust » (Ken Thompson, 1984) : un compilateur compromis produit des binaires malveillants de façon parfaitement déterministe. La compilation est reproductible, mais compromise. La seule défense connue est le diverse double compiling (David A. Wheeler), que Debian n’utilise pas.
Attaque amont (upstream) : le cas XZ de mars 2024 est cité : un backdoor injecté dans le processus de build du tarball amont. Le paquet Debian aurait compilé de façon parfaitement reproductible. « Reproducibilité, protection zéro. »
Reproductibilité faible vs forte : Debian pratique la version faible : on obtient les mêmes bits seulement si on reproduit exactement l’environnement décrit dans le fichier buildinfo. Si l’attaquant contrôle ne serait-ce qu’une dépendance de build enregistrée, la reconstruction confirme l’attaque. C’est « une délégation de confiance, pas une élimination de la confiance ».

L’annonce de Debian : un changement opérationnel, pas une règle de politique

Le 9 mai 2026, l’équipe de publication Debian a annoncé que la migration de unstable vers testing serait bloquée pour les paquets qui échouent au test de reproductibilité, en vue de Debian 14 « Forky » (2027). L’intervenant souligne que le manuel de politique Debian n’a pas été modifié. Le bug n°844443, qui demande depuis 9 ans de passer la reproductibilité de « devrait » à « doit » dans la politique, est toujours ouvert. Ce qui a changé, c’est une règle dans Britney, le script qui gère la migration vers testing. « Une règle Britney est une décision opérationnelle de l’équipe de publication, modifiable, sujette à exceptions, interprétable au cas par cas. » L’intervenant qualifie cela d’« inversion du processus Debian ».

Le chiffre de 98 % de paquets reproductibles : une lecture trompeuse

Le jour de l’annonce, le site de vérification Debian affichait plus de 98 % de paquets reproductibles pour Forky sur toutes les architectures principales (23 728 paquets bons). L’intervenant explique que ce chiffre est « trompeur » car :

Les paquets faciles à rendre reproductibles le sont depuis des années (outils modernes : Meson, Cargo, Go, paquets activement maintenus).
Les 2 % restants sont concentrés là où ça fait le plus mal : code ancien (autotools), générateurs de code avec timestamps embarqués, Java, OCaml, Haskell, paquets scientifiques avec dépendances Fortran, firmware avec blobs binaires. Souvent des paquets orphelins ou maintenus par une seule personne.
Le test du site de vérification normalise fortement l’environnement (chemins, nom de machine, fuseau horaire, langue, nombre de CPU, noyau). C’est la reproductibilité faible. Les 98 % ne signifient pas que n’importe qui recompilant obtiendrait les mêmes bits.

Conséquences opérationnelles pour les mainteneurs et les architectures minoritaires

Pour les mainteneurs des paquets résiduels, le problème devient le leur, même si la cause est amont. Le paquet échoue au test, ne migre pas, et le mainteneur doit choisir entre :

patcher en aval (dette technique permanente),
pousser un correctif en amont (attente de semaines ou mois),
ou voir le paquet retiré de testing. Pour les architectures minoritaires (RISC-V 64, PPC64 EL, S390X, MIPS, Loong64), il y a moins de builders, moins de matériel de test, moins de personnes capables de déboguer des problèmes de reproductibilité spécifiques à l’architecture (codegen, ordre des symboles, packing du linker). Un paquet peut être reproductible sur AMD64 et échouer sur S390X pour des raisons qui exigent un expert de cette architecture. L’intervenant conclut : « La politique crée une pression asymétrique sur les architectures faibles. »

Ce que Debian aurait pu faire mieux

L’intervenant propose quatre améliorations concrètes :

Ratifier la politique avant d’activer l’application, pas six mois après.
Publier un modèle de menace explicite : ce contre quoi on protège, ce contre quoi on ne protège pas, pour que les utilisateurs comprennent ce qu’ils achètent.
Financer une équipe centrale pour attaquer le résidu non reproductible, plutôt que de décharger le coût sur les mainteneurs individuels.
Introduire la barrière progressivement : un avertissement dans unstable, un blocage souple dans testing avec un mécanisme de dérogation publique traçable, un blocage dur uniquement pour les paquets critiques (chaîne d’outils, noyau, init, crypto).
Pousser en parallèle pour de véritables reconstructeurs indépendants : sans tiers qui