Des constructions reproductibles

Les builds reproductibles , également appelées compilation déterministe , sont un processus de compilation de logiciels qui garantit que le code binaire résultant peut être reproduit . Le code source compilé à l'aide de la compilation déterministe produira toujours le même binaire.

Les builds reproductibles peuvent agir comme une partie d'une chaîne de confiance ; le code source peut être signé et une compilation déterministe peut prouver que le binaire a été compilé à partir d'un code source fiable. Les builds reproductibles vérifiées fournissent une contre-mesure solide contre les attaques où les binaires ne correspondent pas à leur code source, par exemple parce qu'un attaquant a inséré du code malveillant dans un binaire. Il s'agit d'une attaque pertinente ; les attaquants attaquent parfois les binaires mais pas le code source, par exemple parce qu'ils ne peuvent modifier que le binaire distribué ou pour échapper à la détection puisqu'il s'agit du code source que les développeurs examinent et modifient normalement. Dans une enquête menée auprès de 17 experts, les builds reproductibles ont obtenu une note d'utilité très élevée de la part de 58,8 % des participants, mais également une note de coût élevé de la part de 70,6 %. Divers efforts sont en cours pour modifier les outils de développement de logiciels afin de réduire ces coûts.

Pour que le processus de compilation soit déterministe, l'entrée du compilateur doit être la même, quel que soit l'environnement de compilation utilisé. Cela implique généralement de normaliser les variables qui peuvent changer, telles que l'ordre des fichiers d'entrée, les horodatages , les paramètres régionaux et les chemins .

De plus, les compilateurs ne doivent pas introduire eux-mêmes de non-déterminisme. Cela se produit parfois lors de l'utilisation de tables de hachage avec une valeur de départ de hachage aléatoire. Cela peut également se produire lors de l'utilisation de l'adresse des variables, car celle-ci varie selon la randomisation de la disposition de l'espace d'adressage (ASLR).

Les systèmes de construction , tels que Bazel et Gitian, peuvent être utilisés pour automatiser les processus de construction déterministes.

Le projet GNU utilisait des versions reproductibles au début des années 1990. Les journaux des modifications de 1992 indiquent que les efforts sont en cours.

L'un des projets les plus anciens Bitcoin avec Gitian. Plus tard, en 2013, le projet Tor (réseau d'anonymat) a commencé à utiliser Gitian pour ses builds reproductibles.

En 2011, un système de compilation Java reproductible a été développé pour un projet FOSS peer-to-peer décentralisé : DirectDemocracyP2P. Les concepts de l'application du système à la prise en charge des recommandations de mises à jour automatisées ont été présentés pour la première fois en avril 2013 lors de la Coordination Décentralisée. Un traité axé sur les détails de mise en œuvre de l'outil de compilation Java reproductible lui-même a été publié en 2015.

En juillet 2013, le projet Debian a commencé à implémenter des builds reproductibles dans l'ensemble de ses archives de paquets. En juillet 2017, il a été prouvé que plus de 90 % des paquets du dépôt étaient construits de manière reproductible.

En novembre 2018, le projet Reproducible Builds a rejoint le Software Freedom Conservancy .

F-droid utilise des builds reproductibles pour garantir que les APK distribués utilisent le code source libre revendiqué .

Le système d'exploitation portable Tails utilise des versions reproductibles et explique aux autres comment vérifier leur distribution.

NixOS revendique une version 100 % reproductible en juin 2021 pour ses versions ISO minimales.

Depuis mai 2020 , Arch Linux travaille à rendre tous les packages officiels reproductibles.

Selon le projet Reproducible Builds, les horodatages sont « la plus grande source de problèmes de reproductibilité. De nombreux outils de build enregistrent la date et l'heure actuelles... et la plupart des formats d'archives enregistreront volontiers les heures de modification en plus de leurs propres horodatages. » Ils recommandent qu'« il est préférable d'utiliser une date pertinente pour le code source plutôt que pour la build : les anciens logiciels peuvent toujours être compilés ultérieurement » s'ils sont reproductibles. Ils identifient plusieurs façons de modifier les processus de build pour y parvenir :

• Définissez la variable d'environnement SOURCE_DATE_EPOCH sur le nombre de secondes écoulées depuis le 1er janvier 1970, en utilisant un élément du code source. Les outils qui prennent en charge cette variable d'environnement utiliseront sa valeur (une fois définie) au lieu de la date et de l'heure actuelles.
• Post-traiter la sortie pour supprimer les horodatages ou les normaliser. L'outil strip-nondeterminism peut souvent aider à faire cela.
• Utilisez une bibliothèque comme libfaketime pour intercepter les requêtes pour l'heure actuelle de la journée et fournir une réponse contrôlée.

Dans certains cas, d'autres modifications doivent être apportées pour rendre un processus de construction reproductible. Par exemple, certaines structures de données ne garantissent pas un ordre stable à chaque exécution. Une solution typique consiste à modifier le processus de construction pour spécifier une sortie triée à partir de ces structures.