Arch Linux bietet jetzt bitgenau reproduzierbare Docker-Images an

 (antiz.fr)
4 Punkte von GN⁺ 5 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bit-für-Bit-Reproduzierbarkeit bedeutet, dass beim Build aus denselben Quellen unabhängig davon, wann, wo oder von wem gebaut wird, ein bis auf Byte-Ebene vollständig identisches Ergebnis entsteht
    • Dafür müssen alle nichtdeterministischen Faktoren wie je nach Build-Umgebung leicht abweichende Zeitstempel, Caches und Metadaten entfernt werden
  • Wenn man das Docker-Image selbst baut und prüft, ob der Digest (Hash) mit dem offiziellen Distributions-Image übereinstimmt, kann jeder unabhängig verifizieren, dass das veröffentlichte Image nicht manipuliert wurde: wichtig für die Sicherheit der Supply Chain
  • Das Docker-Image von Arch Linux wird nun in einer bitgenau reproduzierbaren Form bereitgestellt; damit wird derselbe Meilenstein, der vor einigen Monaten bereits für das WSL-Image erreicht wurde, auf Docker ausgeweitet
  • Dieses Image wird mit dem eigenen repro-Tag ausgeliefert; um die Reproduzierbarkeit zu garantieren, müssen jedoch die pacman-Schlüssel aus dem Image entfernt werden, sodass pacman nicht direkt verwendet werden kann
    • Bis es dafür eine passende Lösung gibt, wird es wegen dieser Einschränkung zunächst unter einem separaten Tag angeboten
  • Um im Container Pakete zu installieren oder zu aktualisieren, muss zunächst mit pacman-key --init && pacman-key --populate archlinux der Keyring neu erzeugt werden
    • Das kann beim ersten Start interaktiv erfolgen oder in der RUN-Anweisung eines Dockerfiles, das dieses Image als Basis verwendet
    • In Distrobox lässt sich das über einen Pre-Init-Hook erledigen, etwa mit distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
  • Die Bit-für-Bit-Reproduzierbarkeit des Images wird über eine übereinstimmende Digest-Prüfung zwischen Builds bestätigt und mit podman inspect --format '{{.Digest}}' <image> sowie einem Vergleich per diffoci verifiziert
  • Wie sich dieses Docker-Image reproduzieren lässt, ist in REPRO.md beschrieben

Umsetzung und Anpassungen

  • Die größte Herausforderung war, das base-rootFS für das Docker-Image deterministisch zu bauen; dabei wurde derselbe Prozess wiederverwendet wie für das WSL-Image, das sich das rootFS-Build-System teilt
    • Den zugehörigen WSL-Commit gibt es hier
  • Zu den Docker-spezifischen Anpassungen gehörte das Setzen von SOURCE_DATE_EPOCH; außerdem wurde das LABEL org.opencontainers.image.created im Dockerfile darauf abgestimmt
  • Im Dockerfile-Schritt wurde die ldconfig-Hilfscache-Datei var/cache/ldconfig/aux-cache entfernt, die im gebauten Image Nichtdeterminismus verursachte
  • Beim Einsatz von docker build oder podman build werden mit --source-date-epoch=$SOURCE_DATE_EPOCH und --rewrite-timestamp Zeitstempel normalisiert
    • Als Beispiel wird ein Problem genannt, bei dem die Zeiten von etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/ unterschiedlich gesetzt wurden
  • Alle zugehörigen Änderungen lassen sich detaillierter im Merge-Request-Diff des archlinux-docker-Repositories nachvollziehen
  • Als nächsten Schritt wird erwogen, für das Docker-Image, das WSL-Image und künftige reproduzierbare Images einen Rebuilder auf einem Server aufzusetzen, um regelmäßige automatische Rebuilds, Reproduzierbarkeitsprüfungen sowie die Veröffentlichung von Build-Logs und Ergebnissen zu ermöglichen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 일 전
Hacker-News-Kommentare

  • Dieses Selbstvertrauen sieht man gern.
    Ich habe fast ein Jahr lang Arch Linux unter WSL 2 genutzt, und es war wirklich gut; danach etwa fünf Monate lang nativ Arch, und auch damit war ich sehr zufrieden.
    Ich nutze weiterhin nativ Arch, und meine dotfiles teste ich mit einem Arch-Docker-Image auf einem sauberen Dateisystem.
    Wenn ich End-to-End-Tests brauche, bei denen sogar eine vollständige Desktop-Umgebung eingerichtet wird, lasse ich Arch in einer VM laufen.
    Ich habe zwar auch genug Probleme, aber zumindest Arch selbst gehört nicht dazu.

    • Ich frage mich, ob es für dotfiles-Änderungen auch staged rollouts oder Rollbacks gibt.
      Ich war auf der Suche nach einem Enterprise-tauglichen dotfiles-Setup mit Prometheus-Metriken und Health Probes, und genau so klingt das.
    • Danke, dass du auch andere Distros unterstützt, und danke fürs Teilen.
      Ich hatte bis gerade eben nie gedacht, dass ich das brauche, aber jetzt brauche ich es plötzlich.
    • Mich würde interessieren, ob du auch NixOS oder Flakes ausprobiert hast.
      Falls ja, würde ich gern hören, wie dein Eindruck war.

  • Ich finde, alle Docker-Container hätten eigentlich schon immer so sein sollen.
    In einem docker build-Schritt apt-get update laufen zu lassen, ist fast schon ein Anti-Pattern.

    • Mit https://github.com/reproducible-containers/repro-sources-lis... gibt es allerdings eine Ausnahme.
      Ich habe es selbst benutzt, und es hat ziemlich gut funktioniert.
    • So oder so ist es nicht wirklich bequem.
      Wenn man nicht aktualisiert, sammeln sich im Container bekannte Sicherheitsprobleme an, und wenn man aktualisiert, geht die Reproduzierbarkeit verloren.
      Reproduzierbarkeit ist zwar eindeutig cool und hat auch Sicherheitsvorteile, aber bei Containern, die älter als einen Monat sind, wirkt das vielleicht schon wie ein Nichtziel, und eine maximale Lebensdauer im Tagesbereich wäre womöglich angemessener.
    • Ich weiß, dass es ein Anti-Pattern ist, aber ich weiß nicht, was die Alternative sein soll, wenn man Software installieren muss.
      Heißt das, man soll getaggten Source Code holen und alles selbst mit gcc kompilieren?
    • Ich stimme nicht zu, das als absolute Regel zu sehen.
      Reproduzierbare Container sind zwar gut, aber nicht immer nötig, und es gibt mehr als genug Fälle, in denen man in einem Container apt-get ausführen kann, ohne sich um Reproduzierbarkeit kümmern zu müssen.
    • Erschwerend kommt hinzu, dass Distros bei Erscheinen neuer Versionen oft die alten Versionen aus den Repos löschen.
      Natürlich gibt es Wege, sie aus Archiven zu holen.

  • Reproduzierbare Images fühlen sich im Alltag oft wie ein Feature an, das vor allem emotionale Befriedigung bringt, aber irgendwann kommt der Tag, an dem man sie wirklich braucht.
    Wir hatten auch schon einmal zwei Images, die identisch hätten sein sollen, aber auf unterschiedlichen Maschinen einen Unterschied von 3 Bytes in einem Zeitstempel erzeugten, und deshalb haben wir einen ganzen Nachmittag damit verschwendet, in die völlig falsche Richtung zu bisecten.
    Nicht glamourös, aber definitiv ein lohnender Sieg.

    • Mich würde interessieren, wie ein Zeitstempelunterschied überhaupt zu einem Ausfall geführt hat.

  • Wahrscheinlich kann man irgendwo etwas einbauen, das allen mitteilt, dass man Arch im CI/CD-Pipeline-Stack nutzt.
    Und gleich noch dazu, dass man Crossfit macht.

    • Das erinnert mich an dieses Koan:
      Wenn man einem veganen Crossfitter begegnet, der Arch benutzt, was erzählt er einem dann zuerst?
    • Ich habe nie verstanden, warum jemand stolz darauf wäre, nicht Slackware zu benutzen.

  • Informationen zu Reproducible Builds gibt es hier:
    https://reproducible-builds.org/
    Die eng verwandte Community zu Bootstrappable Builds ist hier:
    https://bootstrappable.org/

  • Ich frage mich, ob gut designte mutable Betriebssysteme wie Arch oder Alpine langfristig Systeme wie NixOS schlagen könnten.
    Installationsskripte sind ausdrucksstärker als deklarative Konfigurationssprachen und in der Regel auch nicht wortreicher.

    • Dann sollte man vielleicht einfach Guix verwenden.
      Damit bekommt man eine deklarative Konfigurationssprache und gleichzeitig auch noch eine Turing-vollständige, angenehm nutzbare Programmiersprache.
    • Ich frage mich, was mit strictly more powerful hier genau gemeint ist.

  • Ich habe den Artikel gelesen, und das sieht ziemlich cool aus, aber es wirkt, als würden Dockerfile und Docker-Image durcheinandergeworfen.
    Wenn man statt eines Dockerfiles so etwas wie nix verwendet hätte, um die Image-Tar-Datei direkt zu bauen, wäre es vielleicht einfacher gewesen; etwas nerdig zwar, aber wohl trotzdem sauberer.

  • Kleine Anmerkung: Ich finde, der Begriff OCI Image wäre hier treffender.
    Es läuft auch unter podman völlig problemlos.

    • Ich bin in diesem Kommentarbereich eher Anfänger und konnte nicht den ganzen Kontext nachvollziehen, aber das war ein ziemlich augenöffnender Punkt.

  • Großen Respekt an die Leute, die das tatsächlich möglich gemacht haben.
    Der Zeit- und Arbeitsaufwand, der in einer einzigen Schlagzeile wie dieser steckt, ist größer, als man denkt.

  • Ganz anderes Thema, aber auf der Seite gibt es eine Animation, bei der sich fast alle Elemente etwa 20 Pixel nach unten bewegen – und zwar für eine Sekunde.
    Es sah ganz klar so aus, als müsste das den CLS komplett ruinieren, weil sich das Layout direkt vor meinen Augen verschiebt, aber der tatsächliche CLS war 0.
    Da habe ich mich gefragt, ob CLS vielleicht eine irreführende Metrik ist.

    • Das liegt daran, dass es eine absichtliche Animation ist.
      CLS bezieht sich auf Veränderungen beim initialen Rendering, also ist das zwar wie ein Layout Shift sichtbar, wird aber nicht als solcher CLS gezählt.
    • Das ist kein Layout Shift.
      Die Bewegung kommt durch eine CSS transition, also durch eine erwartbare Veränderung, und wird deshalb nicht als Layout Shift berechnet.