Builds reproductibles de NixOS : ISO minimale reconstruite avec succès de manière indépendante

• L’équipe NixOS a mené à bien une reconstruction indépendante et bit à bit identique de l’ISO nixos-minimal publiée par Hydra.
• Le principal avantage des Reproducible Builds est de fournir un moyen fiable de vérifier qu’aucune manipulation n’a eu lieu dans le pipeline de build.
• L’équipe a reproduit tous les paquets inclus dans l’ISO, le build de l’ISO elle-même, ainsi que les paquets nécessaires à la construction de l’ISO qui ne sont pas inclus dans celle-ci.
• La reproduction a été obtenue en démarrant une nouvelle machine VirtualBox avec NixOS 20.03, en clonant le dépôt NixOS, en se plaçant sur un commit précis, puis en exécutant une série de commandes pour construire l’ISO.
• L’équipe reconnaît que cette approche présente un problème potentiel de bootstrap, notamment la possibilité qu’une image ova de 2020 ou le dépôt git téléchargé contiennent une porte dérobée. Néanmoins, ce test offre toujours un niveau de confiance élevé quant à la reproductibilité de l’ISO.
• L’équipe avait déjà annoncé que l’ISO minimale était reproductible à 100 %, mais des problèmes liés au cache Hydra et à la manière dont l’ISO était générée entraînaient des différences. Ces problèmes sont désormais résolus.
• Les travaux à venir incluent la suppression des hacks utilisés dans le processus de reproduction, l’amélioration de la reproductibilité d’un plus grand nombre de paquets, la mise en place d’une infrastructure pour des reconstructions indépendantes régulières, ainsi que la création d’outils pour partager et exploiter des preuves de build.
• L’équipe invite d’autres personnes à rejoindre ses efforts et fournit des liens vers le tableau de projet GitHub et le site web NixOS Reproducible Builds pour plus d’informations.

[GN⁺]

Commentaires sur Hacker News

• Reconstruire une ISO minimale à partir des sources est considéré comme une avancée importante pour pouvoir bâtir un système depuis des sources reproductibles.
• Guix a franchi une étape remarquable en amorçant l’ensemble de la chaîne d’outils de compilation à partir d’un unique binaire reproductible de 357 octets.
• Une question est posée sur la raison pour laquelle la reproductibilité n’est pas le comportement par défaut dans la compilation logicielle.
• Il est proposé que NixOS, comme d’autres distributions Linux, fasse signer les paquets par les mainteneurs afin de vérifier que le code soumis et relu est bien identique à celui qui est compilé.
• Il existe une certaine confusion au sujet de la reproductibilité de NixOS, que certains pensaient être une fonctionnalité centrale du système.
• Le projet OpenBSD est mis en avant pour son approche contrastée, où chaque installation est unique et dispose de décalages d’adresses aléatoires.
• Il est clairement expliqué que la reproductibilité de Nix/NixOS/Nixpkgs ne concerne que les sources, et que les binaires peuvent varier d’un build à l’autre.
• Il est mentionné que d’autres systèmes comme Guix, Archlinux et Debian gèrent mieux la reproductibilité binaire que Nix/NixOS/Nixpkgs.
• Cette étape est saluée comme impressionnante, avec une demande d’informations supplémentaires sur la manière dont l’ISO a été générée.
• Il est suggéré que cette avancée pourrait aider à résoudre le problème du compilateur dérobé évoqué par Ken Thompson dans « Reflections on Trusting Trust ».
• Comme le temps se retrouve souvent intégré dans les binaires, une question est posée sur la nécessité de falsifier l’horloge système pendant ce processus.
• Une comparaison est demandée entre cette évolution et Fedora Silverblue, Ansible, ainsi que Fedora Silverblue + Ansible au sein de l’écosystème Red Hat.