Arch Linux propose désormais des images Docker reproductibles bit pour bit

• La reproductibilité bit pour bit signifie qu’en construisant à partir des mêmes sources, on obtient un résultat totalement identique jusqu’au niveau des octets, quel que soit le moment, l’endroit ou la personne qui effectue le build
  • Pour y parvenir, il faut éliminer tous les facteurs non déterministes comme les horodatages, les caches ou les métadonnées qui peuvent varier subtilement selon l’environnement de build
• En construisant soi-même l’image Docker puis en comparant si son digest (hash) est identique à celui de l’image officielle distribuée, n’importe qui peut vérifier indépendamment que l’image publiée n’a pas été altérée : c’est un point important du point de vue de la sécurité de la chaîne d’approvisionnement
• L’image Docker d’Arch Linux est désormais fournie sous une forme reproductible bit pour bit, étendant au côté Docker le même jalon atteint il y a quelques mois pour l’image WSL
• Cette image est distribuée avec le tag dédié repro et, pour garantir la reproductibilité, il faut supprimer les clés pacman de l’image, ce qui empêche d’utiliser immédiatement pacman
  • En attendant qu’une solution appropriée soit trouvée, cette contrainte justifie pour l’instant une diffusion via un tag séparé
• Pour installer ou mettre à jour des paquets dans le conteneur, il faut d’abord exécuter pacman-key --init && pacman-key --populate archlinux afin de régénérer le keyring
  • Cela peut être fait de manière interactive lors de la première exécution, ou dans une instruction RUN du Dockerfile basé sur cette image
  • Dans Distrobox, cela peut être géré via un hook de pré-initialisation, par exemple distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
• La reproductibilité bit pour bit de l’image est vérifiée par la correspondance du digest entre les builds, à l’aide de podman inspect --format '{{.Digest}}' <image> et d’une comparaison avec diffoci
• La méthode pour reproduire cette image Docker est décrite dans REPRO.md

Implémentation et ajustements

• Le plus grand défi a été de construire de manière déterministe le rootFS de base destiné à l’image Docker, en réutilisant le même processus que pour l’image WSL, qui partage le même système de build du rootFS
  • Le commit WSL associé peut être consulté ici
• Parmi les ajustements spécifiques à Docker, l’un consiste à définir SOURCE_DATE_EPOCH et à faire en sorte que le LABEL org.opencontainers.image.created du Dockerfile s’y conforme également
• Le fichier de cache auxiliaire var/cache/ldconfig/aux-cache de ldconfig, source de non-déterminisme dans l’image générée, est supprimé à l’étape du Dockerfile
• Lors de docker build ou podman build, les options --source-date-epoch=$SOURCE_DATE_EPOCH et --rewrite-timestamp sont utilisées pour normaliser les horodatages
  • L’exemple donné mentionne des écarts d’horodatage entre etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/
• L’ensemble des modifications associées peut être consulté plus en détail dans le diff de la merge request du dépôt archlinux-docker
• La prochaine étape envisagée consiste à mettre en place sur serveur un rebuilder pour l’image Docker, l’image WSL et les futures images reproductibles, afin d’automatiser des reconstructions périodiques, la vérification de la reproductibilité, ainsi que la publication des logs de build et des résultats

[GN⁺]

Commentaires sur Hacker News

• C’est agréable de voir une telle confiance
  J’ai fait tourner Arch Linux sur WSL 2 pendant presque un an et c’était excellent, puis j’ai utilisé Arch en natif pendant environ 5 mois et j’en ai aussi été très satisfait
  J’utilise toujours Arch en natif aujourd’hui, et mes dotfiles sont testés sur un système de fichiers propre avec une image Docker Arch
  Quand j’ai besoin de tests de bout en bout qui vont jusqu’à configurer un environnement de bureau complet, je fais tourner Arch dans une VM
  J’ai moi aussi beaucoup de problèmes, mais au moins Arch n’en fait pas partie

  • Je me demande s’il y a aussi des staged rollouts ou des rollbacks pour les changements de dotfiles
    J’étais justement à la recherche d’une configuration de dotfiles de niveau entreprise avec métriques Prometheus et health probes, donc ça en donne exactement l’impression
  • Merci de prendre en charge d’autres distros, et merci aussi d’avoir partagé ça
    Je n’avais jamais pensé en avoir besoin, mais dès que je l’ai vu, j’en ai eu besoin
  • Je me demande si tu as aussi essayé NixOS ou les flakes
    Si oui, j’aimerais bien savoir ce que tu en as pensé

• À mon avis, tous les conteneurs Docker auraient dû être conçus comme ça dès le départ
  Faire un apt-get update pendant l’étape de docker build, c’est quasiment un antipattern

  • Cela dit, avec https://github.com/reproducible-containers/repro-sources-lis..., ça devient une exception
    Je l’ai utilisé moi-même et ça marchait plutôt bien
  • Dans un cas comme dans l’autre, ce n’est jamais totalement confortable
    Si on ne met pas à jour, des problèmes de sécurité connus s’accumulent dans le conteneur, et si on met à jour, on casse la reproductibilité
    La reproductibilité est clairement chouette et apporte aussi des avantages en matière de sécurité, mais au bout d’un mois un conteneur peut déjà donner l’impression de rater sa cible, et une durée de vie maximale de l’ordre de la journée serait peut-être plus appropriée
  • Je comprends que ce soit un antipattern, mais je ne vois pas quelle est l’alternative quand on doit installer un logiciel
    Ça veut dire récupérer le code source tagué et tout compiler soi-même avec gcc ?
  • Je ne suis pas d’accord pour en faire une règle absolue
    Les conteneurs reproductibles, c’est très bien, mais ce n’est pas toujours nécessaire, et il y a aussi beaucoup de cas où on peut exécuter apt-get dans le conteneur sans se soucier de la reproductibilité
  • C’est aussi plus difficile parce que beaucoup de distros suppriment les anciennes versions de leurs dépôts dès qu’une nouvelle sort
    Bien sûr, il existe des moyens de passer par les archives

• Les images reproductibles donnent souvent l’impression d’être une fonctionnalité qui n’apporte au quotidien qu’une satisfaction émotionnelle, mais il arrive un jour où elles deviennent indispensables
  Chez nous, deux images censées être identiques ont fini par différer de 3 octets dans un timestamp sur deux machines différentes, et ça nous a fait perdre tout un après-midi à faire un bisect dans la mauvaise direction
  Ce n’était pas spectaculaire, mais c’était clairement une victoire qui avait de la valeur

  • Je me demande quand même comment un écart de timestamp a pu provoquer une panne au départ

• On pourrait probablement y ajouter quelque chose qui informe tout le monde qu’on utilise Arch dans sa pipeline CI/CD
  En même temps que le fait qu’on fait du CrossFit, bien sûr

  • Ça me rappelle ce koan
    Si on rencontre quelqu’un qui est à la fois vegan, adepte de CrossFit et utilisateur d’Arch, qu’est-ce qu’il dira en premier
  • Je n’ai jamais compris pourquoi quelqu’un serait fier de ne pas utiliser Slackware

• On peut trouver des infos sur les Reproducible Builds ici
  https://reproducible-builds.org/
  La communauté des Bootstrappable Builds, très liée au sujet, est ici
  https://bootstrappable.org/

• Je me demande si, sur le long terme, des systèmes comme Arch ou Alpine, qui sont des systèmes d’exploitation mutables bien conçus, pourraient battre des systèmes comme NixOS
  Parce que les scripts d’installation sont plus expressifs qu’un langage de configuration déclaratif, sans être en général plus verbeux

  • Dans ce cas, autant utiliser Guix
    On a un langage de configuration déclaratif, mais aussi un langage de programmation à la fois Turing-complet et agréable à écrire
  • Je me demande ce que veut dire exactement strictly more powerful

• J’ai lu l’article et ça a l’air plutôt cool, mais j’ai l’impression qu’il mélange Dockerfile et image docker
  Ça aurait sans doute été plus simple de construire directement le tar de l’image avec quelque chose comme nix au lieu d’un Dockerfile ; ce serait certes un peu plus ésotérique, mais aussi plus propre

• Petite remarque, mais je pense qu’il serait plus juste d’utiliser le terme OCI Image
  Ça fonctionne aussi très bien avec podman

  • Je suis un peu novice dans cette section de commentaires, donc je ne suis pas sûr de suivre tout le contexte, mais ça m’a semblé être un point assez révélateur

• Beaucoup de respect pour les personnes qui ont réellement rendu ça possible
  Le temps et les efforts nécessaires pour arriver à un titre comme celui-ci dépassent l’imagination

• Rien à voir, mais il y a une animation sur cette page qui fait descendre presque tous les éléments d’environ 20 pixels pendant une seconde
  En voyant la mise en page bouger sous mes yeux, j’étais persuadé que ça allait massacrer le CLS, mais le CLS réel était de 0
  Du coup, je me demande si le CLS n’est pas une métrique trompeuse

  • C’est dû au fait que c’est une animation intentionnelle
    Le CLS traite des changements au moment du rendu initial, donc même si ça ressemble à un déplacement de mise en page, ce n’est pas le type de chose comptabilisé dans le CLS
  • Ce n’est pas un layout shift
    C’est un mouvement dû à une transition CSS, donc un changement prévisible, qui n’est pas compté comme layout shift