Le 9 janvier 2019, dans le cadre de la Cryptoparty rennaise, nous avions proposé à Chris Lamb, alors développeur Debian, de venir faire une conférence sur les compilations reproductibles (reproducible builds)1. La conférence a bien eu lieu dans l’amphi de l’ISTIC en présence d’une audience assez nombreuse, a priori constituée plutôt d’enseignants et d’étudiants en informatique. J’en ai gardé un souvenir plus vif que celle de Richard Stallman qui a eu lieu quelques mois plus tard. Pourtant à la base le sujet de C. Lamb me paraissait plus hermétique que celui de Stallman et surtout moins folklorique. Stallman envoyait nombre de signes de connivence à son auditoire, Lamb essayait simplement de rendre explicite son “conte des trois développeurs” aux personnes présentes et de nous faire partager le cheminement de sa pensée nourrie d’une expérience et d’un point de vue particuliers, ceux d’un manager qui se situe en amont d’une chaîne de fourniture (supply chain) de logiciels packagés et livrés signés par des développeurs de Debian.
J’ai relu récemment les notes que j’avais prises lors de cette soirée ainsi que la publication qui est parue trois ans plus tard dans IEEE Software et dont cette conférence est issue 2.
Lamb insiste d’abord sur le fait que le problème des compilations non reproductibles n’est pas seulement un enjeu de maîtrise du principe de compilation au sens informatique d’un outil imparfait qui ne distinguerait pas bien certaines variables du code source à compiler.
Il part du constat que ce que les gens téléchargent et installent aujourd’hui, ce ne sont pas les sources elles mêmes mais les exécutables qui leur permettent d’utiliser le code sans avoir à le compiler (et qui leur vient sous la forme de fichiers du type Download.exe /.deb /.rpm, etc.).
Ainsi, la plupart du temps, lorsqu’on télécharge du code source libre, on accorde sa confiance non pas à un mais trois tiers : - celui qui produit le code (et dont on espère qu’il n’y a pas introduit volontairement ou involontairement une backdoor)
- celui qui relit le code. Or cette personne n’existe peut-être pas, et en tout cas peut se faire attendre. On l’a déjà vu pour la faille Heartbleed qui a affecté pendant deux ans le protocole OpenSSL avant d’être découverte. On l’a encore revu récemment avec la librairie XZutils : ce n’est pas parce que du code est auditable qu’il sera forcément audité, loin s’en faut.
- celui qui compile les sources et fournit les exécutables. En l’occurence, pour Debian, c’est l’orateur lui-même qui était alors responsable de cette activité.
Le dernier tiers est faillible comme les précédents. Il peut en effet utiliser un outil de compilation non déterministe qui va insidieusement intégrer des éléments indésirables dans le résultat de la compilation. Cela aura pour conséquence de modifier la somme obtenue et dissuader l’utilisateur final. Mais il peut aussi délibéremment3 ou bien à son insu compiler du code source sûr avec un compilateur compromis qui va injecter une backdoor dans l’exécutable durant le processus.
Si l’exécutable est chargé depuis différents serveurs miroirs, et si ces miroirs sont compromis alors l’exécutable pourra être infecté. Il est donc très important que le processus de compilation soit transparent et que la chaîne de livraison du code soit maîtrisée.
Parmi les paramètres qui rendent les compilations non reproductibles, Lamb a énuméré les suivants :
- le timestamp (date et heure de l’opération qui ne devrait pas être présente dans le résultat). C. Lamb cite la documentation de LaTeX qui intègre la date à laquelle celle-ci est compilée dans le résultat de la compilation.
- l’ordre de lecture des fichiers prévu par le programme qui n’est pas déterminé par défaut dans les systèmes d’exploitation Unix.
- les chemins vers les fichiers (filsystem)
- certains fichiers qui comportent une mémoire qui n’est pas réinitialisée (système d’allocation de mémoire FAT)
Chris Lamb a montré ensuite comment l’équipe des développeurs de Debian a appris peu à peu à créer des compilations déterministes au moyen d’un système d’intégration continue qui comporte des compilations faites sur des machines très différentes (dont l’horloge par exemple est réglée sur des dates très distantes). Le repérage de ces variations permet d’identifier les éléments qui viennent apporter de l’aléatoire dans le processus de la compilation et cet aléatoire est peu à peu réduit par l’ajout de fonctions supplémentaires dans le code source, comme par exemple la fonction sort() qui permet d’ordonner la lecture des fichiers.
Si j’ai abordé la question de la reproductibilité du logiciel par l’angle de la sécurité, ce n’est évidemment pas un hasard, puisque depuis 2015, en tant que bibliothécaires, Chloé Lailic et moi-même travaillions à populariser les logiciels comme Tor, Tails ou encore les stores d’applications libres comme F-Droid. Ce sont les développeurs de ces applications qui, comme ceux de Debian, poussent à une meilleure reproductibilité des compilations afin d’assurer leurs utilisateurs de l’intégrité des exécutables livrés. Pour beaucoup d’utilisateurs dans le monde, cette assurance est une condition sine qua non de leur usage.
Toutefois, depuis que je m’intéresse à la reproductibilité du code dans le cadre des expérimentations scientifiques, l’intérêt de la Science reproductible m’apparaît évident dans cet effort collectif vers une sécurité accrue. Sans doute les processus employés pour parvenir à cette autre forme de reproductibilité seront différents. La vérification des sommes ne sera pas aussi indispensable aux chercheurs qu’il ne l’est aux gestionnaires de logiciels et aux développeurs. Mais l’essor d’outils comme Guix qui permettent de livrer des applications avec l’enironnement nécessaire pour les faire fonctionner sur tous les ordinateurs GNU/Linux me rendent confiant dans le fait que cette question de la reproductibilité du code de recherche devrait s’avérer incontournable dans les prochaines années.
Footnotes
annonce de la conférence disponible sur un snapshot du site Breizh Entropy dans Internet Archive↩︎
[1] C. Lamb et S. Zacchiroli, « Reproducible Builds: Increasing the Integrity of Software Supply Chains», IEEE Software, vol. 39, nᵒ 2, p. 62‑70, mars 2022, doi: 10.1109/MS.2021.3073045.↩︎
par “volontairement”, C. Lamb entend plusieurs nuances différentes de “volonté” et mentionne la possibilité je cite que le développeur “gets blackmails by an unknown person who introduces a different compiler” soit l’objet d’un chantage par une personne qui lui force la main pour l’obliger à utiliser son compilateur à lui plutôt que celui dont le développeur se sert habituellement.↩︎