Reproduzierbare Builds in NixOS: Unabhängiger Neuaufbau der minimalen Installations-ISO erfolgreich

 (discourse.nixos.org)
1 Punkte von GN⁺ 2023-10-30 | 1 Kommentare | Auf WhatsApp teilen
  • Die minimale Installations-ISO von NixOS lässt sich unabhängig bitgenau identisch zum Hydra-Distributionsartefakt neu erstellen und zeigt damit, dass sich die Übereinstimmung von ausgelieferten Binärdateien und Quellcode verifizieren lässt
  • Diese Verifikation reproduziert nicht nur die in der ISO enthaltenen Pakete, sondern auch den ISO-Erstellungsprozess selbst und deckt damit einen größeren Bereich ab als reine Paket-Reproduzierbarkeit
  • Der Neuaufbau startete von einer NixOS-20.03-VirtualBox-Appliance, nutzte die nixpkgs-Revision 63678e9f3d3a und schaltete mit --option substitute false die Abhängigkeit von Binär-Caches aus
  • Falls die OVA von 2020 oder das heruntergeladene git eine ausgefeilte Backdoor enthalten hätten, wäre das weiterhin ein Angriffsvektor; eine Verifikation auf Basis eines vollständig gebootstrappten Systems steht also noch aus
  • Der Neuaufbau der minimalen ISO ist ein wichtiger Meilenstein, aber das Entfernen provisorischer Workarounds, die Reproduktion weiterer Installationsmedien, regelmäßige Infrastruktur für unabhängige Neuaufbauten und Tools für Build-Nachweise sind die nächsten Aufgaben

Verifizierte Reproduzierbarkeit bei der minimalen ISO

  • Der von Hydra veröffentlichte nixos-minimal-ISO-Build wurde unabhängig neu gebaut und ergab ein bitgenau identisches Artefakt
  • Der Reproduktionsumfang teilt sich in zwei Bereiche
    • alle Pakete, die in die ISO eingehen
    • der Build-Prozess selbst, der die ISO erzeugt
  • Es wurden auch Pakete mitgebaut, die für den ISO-Build nötig sind, aber nicht in der ISO enthalten sind, und es bestand keine Abhängigkeit von zwischengespeicherten Binärdateien
  • Reproduzierbare Builds schaffen einen Vertrauenspfad, um zu prüfen, ob Distributions-Binärdateien dem Quellcode entsprechen und in Build-Pipelines wie Hydra nicht manipuliert wurden

Ablauf des Neuaufbaus und Grenzen

  • Der Neuaufbau wurde von einer frischen VirtualBox-Appliance mit NixOS 20.03 aus durchgeführt
    • CPU und Arbeitsspeicher wurden großzügig zugewiesen und die Festplatte auf etwa 65 GB erweitert
    • Nach der Installation von git wurde nixpkgs geklont und die Revision 63678e9f3d3a ausgecheckt
    • Mit --option substitute false wurden benötigte Komponenten nicht aus dem Binär-Cache bezogen, sondern auf der lokalen Maschine gebaut
  • Das Verfahren enthielt provisorische Maßnahmen, um bekannte Probleme zu umgehen
  • Bei der Vertrauenswürdigkeit der Supply Chain bleiben Einschränkungen bestehen
    • Wenn die OVA von 2020 oder das heruntergeladene git eine ausgefeilte Backdoor enthalten hätten, wäre das weiterhin ein Angriffsvektor
    • Ein Neuaufbau auf einem vollständig bootstrappeden System wäre besser, aber dieses Stadium ist noch nicht erreicht
    • Weitere Fortschritte werden im Thread zum nixpkgs supply-chain security project diskutiert

Unterschied zur Ankündigung von 2021

  • 2021 gab es eine Ankündigung, dass die minimale ISO zu 100 % reproduzierbar sei, doch damals wurden nur die für den ISO-Build nötigen Pakete einzeln reproduziert; beim tatsächlichen Neuaufbau der ISO blieben Unterschiede bestehen
    • Ursache waren verbleibende Probleme mit dem Hydra-Cache und der Art, wie die ISO erzeugt wurde
    • Während diese Probleme behoben wurden, traten Regressionen wie ein Upstream-Problem in Python 3.10 auf, und erst in dieser Woche war die gesamte Kette wieder in einem Zustand, in dem sie verifiziert werden konnte
  • Die nächsten Schritte umfassen das Entfernen provisorischer Workarounds, die Reproduktion weiterer Pakete und die Reproduktion anderer Installationsmedien wie der Gnome-ISO
  • Außerdem werden Infrastruktur für regelmäßige unabhängige Neuaufbauten sowie Werkzeuge zum Teilen und Nutzen von Build-Nachweisen wie trustix benötigt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-30
Meinungen auf Hacker News

  • Dass die Minimal-ISO aus den Quellen neu gebaut wurde, ist ein beeindruckender Meilenstein auf dem Weg zu einem System, das sich aus den Quellen reproduzierbar bauen lässt.
    Guix hat kürzlich auf derselben Reise einen orthogonalen, aber ebenso beeindruckenden Erfolg erzielt: Es bootstrapped die gesamte Compiler-Toolchain aus einem einzigen reproduzierbaren 357-Byte-Binary, ohne weitere binäre Compiler-Blobs.
    Vielleicht werden diese beiden Ansätze bald kombiniert, sodass sich eine ganze Distribution aus den Quellen reproduzierbar bauen lässt.
    https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

    • Großartig, und es ist schön zu sehen, dass es Leute gibt, die den guten Kampf führen, selbst bei Reaktionen wie „Wenn es eine Backdoor gibt, bekommen dann nicht ohnehin alle dieselbe Backdoor?“
      Der zentrale Punkt, den viele nicht verstehen: Es geht nicht darum zu beweisen, dass das Ergebnis zu 100 % vertrauenswürdig ist, sondern darum zu beweisen, dass das Ergebnis den Quellen zu 100 % entspricht.
      Das heißt: Wenn verdächtige Dinge wie eine versteckte Backdoor entdeckt werden, kann man sie immer deterministisch reproduzieren.
      Aus Sicht der Angreifer gibt es dann keinen Ort mehr zum Weglaufen oder Verstecken.
    • Es ist noch nicht so weit wie Guix’ stage0, aber auf der NixCon gab es einen interessanten Vortrag darüber, Nix aus TinyCC heraus zu bootstrappen: https://media.ccc.de/v/nixcon-2023-34402-bootstrapping-nix-a...
    • Dass das Bootstrap-Compiler-Binary 357 Byte groß ist, ist wirklich beeindruckend.
    • Bei 357 Byte frage ich mich, ob man überhaupt ein reproduzierbares Binary braucht.
      Man könnte vermutlich die gesamten 357 Byte Maschinencode von Hand dokumentieren und für Menschen verständlich machen.

  • Ich habe so etwas noch nie gemacht, daher ist die Frage vielleicht dumm, aber ich frage mich, warum Reproduzierbarkeit nicht das Standardverhalten ist.
    Wenn man zwei Kopien einer Software aus denselben Quellen kompiliert, verstehe ich nicht recht, was verhindert, dass sie jedes Mal exakt identisch werden.
    Ich weiß, dass es viele bewegliche Teile gibt, aber ich verstehe immer noch nicht, wie die Unterschiede entstehen.

    • Es gibt viele konkrete Ursachen, und Zeitstempel sind vermutlich das häufigste Problem.
      Eine Liste häufiger Probleme findet man hier: https://reproducible-builds.org/docs/
      Der übergreifende Kernpunkt ist, dass Entwickler nicht testen, ob Builds reproduzierbar sind.
      Wenn es in die Release-Tests aufgenommen wird, bleibt es in der Regel weiterhin reproduzierbar.
    • Es gibt sehr viele Ursachen.
      Typische Beispiele, die explizit Nicht-Reproduzierbarkeit erzeugen, sind Zeitstempel und Autoreninformationen.
      Es gibt auch Stellen, die die standardmäßige Reproduzierbarkeit implizit brechen: Viele Runtimes definieren zum Beispiel die Reihenfolge von Hashmap-Einträgen nicht, und ein Compiler kann über diese Hashmap iterieren, um ein Binary zu erzeugen.
    • Es kann an Parallelität liegen.
      Es kann Aufgaben geben, bei denen die Reihenfolge nicht egal ist, und je nach CPU-Zustand entsteht ein leicht anderes Binary, obwohl alle Ergebnisse korrekt sind.
    • Das Go-Team hat kürzlich einen Artikel darüber veröffentlicht, was es getan hat, um die Go-Toolchain vollständig reproduzierbar zu machen: https://go.dev/blog/rebuild
    • Manchmal liegt es an randomisierten Algorithmen, manchmal an Performance-Gründen, etwa wenn es schneller ist, etwas nicht zu sortieren.
      Manchmal sind auch Metadaten, die von Zeit oder Umgebung abhängen, oder die Ausführungsreihenfolge von Threads die Ursache.

  • Entschuldigung, wenn ich da etwas nicht verstehe, aber ich dachte, einer der Hauptgründe für NixOS sei Reproduzierbarkeit.
    Ich dachte, diese Probleme seien bereits gelöst.
    Ich habe NixOS nur etwa zwei Stunden ausprobiert und wollte Hyprland testen; da Hyprland etwas Konfiguration braucht, dachte ich, es wäre unter NixOS einfacher als bei anderen Distributionen, fremde Konfigurationen zu übernehmen.
    Aber es war schwierig, Konfigurationen zu finden, und ich habe zwar etwa drei in beliebigen GitHub-Gists gefunden, doch keine davon funktionierte, also habe ich aufgegeben.

    • NixOS hat den Vorteil, dass alles in seiner eigenen Sandbox gebaut wird, nur mit explizit deklarierten und gehashten Abhängigkeiten.
      Es hängt nicht wie eine normale Distribution von der gesamten Systemumgebung ab, daher entstehen in vielen Fällen schon jedes Mal dieselben Binaries.
      Der Build-Prozess selbst kann jedoch in vielen Paketen nichtdeterministisch sein, sodass das allein nicht sofort vollständige Reproduzierbarkeit ergibt.
    • Reproduzierbarkeit hat zwei Bedeutungen.
      Die Bedeutung, an die du denkst, ist: Wenn man Binärpakete einfach neu baut, werden dieselben Abhängigkeitsversionen, Build-Optionen usw. verwendet.
      Es sollte also keinen Raum für neue Kompilierfehler wie „auf meinem Laptop hat es funktioniert“ geben.
      Die hier gemeinte Bedeutung ist, dass alle Build-Artefakte bytegenau identische Binaries werden.
      Sie dürfen nicht vom Maschinennamen, vom Kompilierzeitpunkt, von der Reihenfolge, in der bei parallelen Builds Dateien fertig kompiliert werden, usw. abhängen; das ist deutlich schwieriger.
    • Nix ist ein schwer zu lernendes Werkzeug.
      Wenn man nicht damit vertraut ist, ist es kaum das Tool, das man wählt, wenn man „etwas will, das sofort funktioniert“.
      Wenn man bei NixOS von „reproduzierbar“ spricht, bedeutet das eher: „Mit demselben Nix-Code erhält man dasselbe Programmverhalten.“
      Das ähnelt dem, was Leute von einem Dockerfile erwarten, und zielt darauf ab, Probleme wie „auf meiner Maschine ging es“ oder „beim letzten Mal ging es“ zu lösen.
      „Reproduzierbare Builds“ hingegen zielen darauf ab, dass auf verschiedenen Maschinen erzeugte Artefakte bitgenau identisch sind.
      Dadurch entsteht eine zusätzliche Sicherheitsebene, weil man verifizieren kann, dass Code aus einer bestimmten Menge von Quellen gebaut wurde.
      Mich würde auch interessieren, welche Suchbegriffe du verwendet hast, um Konfigurationen zu finden.
      Wenn man nach „nixos configuration“ sucht, erhält man Ergebnisse wie https://github.com/search?q=nixos%20configuration&type=repos..., und selbst nur für Hyprland findet man mit https://github.com/search?q=wayland.windowManager.hyprland&t... ziemlich viel.

  • https://github.com/donovanglover/nix-config ist einen Blick wert
    Eine Flake-basierte Konfiguration, mit Hyprland und mehreren ziemlich guten Dingen darin
    Aktuell ist NixOS kein Werkzeug für schwache Nerven oder für Leute mit wenig Zeit
    Ich hoffe, dass sich das irgendwann ändert, aber wenn man durchhält und darüber hinwegkommt, kann man die Vorteile mitnehmen

  • Man sollte sich merken, dass Reproduzierbarkeit bei Nix / NixOS / Nixpkgs Reproduzierbarkeit der Quellen bedeutet
    Wenn sich die Quellen ändern, bekommt man eine Warnung, aber das ist etwas anderes als die Reproduzierbarkeit von Binaries, die bei jedem Build anders ausfallen können
    Die Binary-Reproduzierbarkeit von Nix / NixOS / Nixpkgs wird zumindest systematisch eher nicht gut getestet
    Guix, Arch Linux und Debian behandeln Binary-Reproduzierbarkeit besser als Nix / NixOS / Nixpkgs
    Quellen: https://r13y.com/ (Nix*) / https://tests.reproducible-builds.org/debian/reproducible.ht... (Debian) / https://tests.reproducible-builds.org/archlinux/archlinux.ht... (Arch Linux) / https://data.guix.gnu.org/repository/1/branch/master/latest-... (Guix, das Laden kann langsam sein; eine gecachte Kopie gibt es unter https://archive.is/lTuPk)

    • In diesem Kontext gibt es zwei Definitionen von „Reproduzierbarkeit“
      Eingabe-Reproduzierbarkeit bedeutet „perfekte Cache-Invalidierung für Eingaben“
      Nix und Guix leisten das von Grund auf perfekt und lösen gelegentlich sogar zu viele Rebuilds aus
      Debian und Arch Linux betrachten das nicht als Hauptanliegen und behandeln die Frage, welche Pakete neu gebaut werden sollen, wenn bestimmte Quelldateien aktualisiert werden, mit provisorischen Ansätzen wie manuellen Rebuild-Triggern
      Ausgabe-Reproduzierbarkeit bedeutet „der Build-Prozess ist deterministisch und erzeugt immer dieselbe Binary“; das ist das Thema des ursprünglichen Artikels
      Nix baut Pakete in einer Sandbox, was hilft, aber keine Allzwecklösung ist
      In dieser Hinsicht sitzt Nix im selben Boot wie Debian und Arch Linux
      Tatsächlich schicken Distributionen oft Patches upstream, um die Reproduzierbarkeit zu erhöhen, und andere Distributionen profitieren ebenfalls davon
      In diesem Kontext ist https://reproducible.nixos.org das Gegenstück zu den anderen genannten Links, und ich stimme zu, dass der Nix-Bericht weniger detailliert ist; das bedeutet aber nicht, dass die Binary-Reproduzierbarkeit von Nix schlechter ist
      Wenn man das als „Nix ist nur bei Eingabe-Reproduzierbarkeit gut, aber nicht bei Binary-Reproduzierbarkeit“ liest, wäre das falsch
      Genau diesen Meilenstein feiern wir hier
    • Es wäre wohl gut, den Artikel zu lesen
      Darin geht es nicht nur um Binaries, sondern auch darum, wie sie als ISO paketiert werden, bitgenau zu reproduzieren
      r13y.com ist veraltet, und die fehlenden weniger als 1 % waren meiner Erinnerung nach auf eine upstream-Python-Regression zurückzuführen
      Die Reproduzierbarkeit der Binaries selbst war, abgesehen vom ISO-Packaging, bereits vor einigen Jahren erreicht
      Sobald man über die Kern-ISO hinaus zu weiteren Paketen geht, wird der Vergleich kompliziert
      Die Art, wie Pakete behandelt werden, unterscheidet sich subtil, aber in diesem Kontext wesentlich; viele Pakete, die bei Arch vermutlich im AUR lägen, sind bei Nix als normale Pakete enthalten, und die meisten upstream--bin-Pakete sind bei Nix schlicht nicht nötig
      Im Allgemeinen macht Nix es leichter, reproduzierbare Builds zu erstellen, aber unabhängig von Nix ist das nicht immer möglich und erfordert oft Patches
      Wenn man außerdem bedenkt, dass das Standard-Paket-Repository von Nix über 80.000 Pakete enthält, während Arch ohne AUR weniger als 15.000 hat, sind Prozentvergleiche nicht besonders nützlich
      Ein sehr verbreitetes Missverständnis ist, dass der Hash eines Nix-Store-Pfads auf der Build-Ausgabe basiert; tatsächlich basiert er auf allen Quellen und Eingaben, die zum Bauen der Binary in einer isolierten Umgebung verwendet wurden, unabhängig davon, ob es sich dabei um Binaries handelt oder nicht
      Dadurch entstehen die erwarteten Sicherheitsvorteile nicht unverändert, aber dafür kann auch Software, die nicht reproduzierbar gebaut wird, in einer vernünftig reproduzierbaren Distributionsform genutzt werden, mit gleichen Features, Compiler-Einstellungen, Abhängigkeitsversionen, Nutzern, Konfigurationen usw.
    • Ich glaube, genau darum geht es doch in der ersten Quelle und im ursprünglichen Artikel
      Es wird geprüft, ob die Binary identisch ist, wenn man aus denselben Quellen auf unterschiedlichen Maschinen baut
      Der Punkt ist, dass sich die Binary nicht bei jedem Build ändert
      Auch zur Testmethode heißt es, dass jeder Build zweimal zu unterschiedlichen Zeitpunkten, auf unterschiedlicher Hardware und mit unterschiedlichen Kernels ausgeführt wird
    • Ich wusste nicht, dass Arch Linux Reproduzierbarkeit testet
      Dort steht offenbar, dass 85,6 % reproduzierbar sind: https://reproducible.archlinux.org
      Ich frage mich, wie viel Arbeit dafür bei NixOS nötig wäre, wo es über 80.000 Pakete in den offiziellen Repositories gibt

  • Angesichts der Ziele oder der Realität von nixpkgs ist das überhaupt nicht zutreffend.
    Im ursprünglichen Beitrag geht es darum, ein binäres Minimal-ISO zu reproduzieren, das mehrere Binärpakete enthält.

  • Es ist ironisch und witzig, dass das OpenBSD-Projekt energisch in die genau entgegengesetzte Richtung geht.
    OpenBSD hat bei jeder Installation eindeutige, randomisierte Adress-Offsets.
    Ich verstehe, dass die beiden Ziele reproduzierbare Builds und eine eindeutige Installation orthogonal zueinander stehen und gleichzeitig erreichbar sind, aber diese Dualität ist trotzdem amüsant.

    • Wenn sich die Adress-Offsets mit einem bereitgestellten Seed randomisieren lassen, kann man Reproduzierbarkeit weiterhin nachweisen.
      Oder man könnte die Offsets beim Programmstart randomisieren, was die Reproduzierbarkeit erhält und zugleich die Sicherheit erhöht.
      Dann würde sich der Offset bei jeder Ausführung ändern.
    • OpenBSD führt beim Booten randomisiertes Linking durch.
      Die Pakete selbst können weiterhin reproduzierbar sein.
      Die gesamte Randomisierung erfolgt lokal, nachdem die Pakete heruntergeladen und die Prüfsummen verifiziert wurden.

  • Jetzt wäre es schön, wenn die Maintainer die Pakete einfach signieren würden, so wie es seit den 90ern fast alle anderen Linux-Distributionen tun.
    Dann wüssten alle zumindest bis zu einem gewissen Grad, dass der Code, den sie bauen, derselbe Code ist, der von bekannten Personen eingereicht und geprüft wurde.
    Bevor Signaturen standardisiert sind, kann ich mir schwer vorstellen, Nix in der Produktion für etwas zu verwenden, das einen schützenswerten Wert hat.

    • Ich sehe Nix-Paket-Maintainer eher als Leute, die nützliche Schnittstellen bereitstellen, mit denen sich Software leicht kombinieren lässt.
      Die meisten geben keinerlei Garantie für den Paketinhalt.
      Von ihren Signaturen sinnvolle Zusicherungen zu erwarten, fühlt sich ungefähr so an, als würde man vom Lieferfahrer Produktsupport erwarten.
      Man muss auch nicht darauf vertrauen, dass nichts bösartig paketiert wurde.
      Da Nix reproduzierbare Builds macht, kann man sich die derivation ansehen und selbst bauen, wenn man sich nicht auf den Binary Cache verlassen möchte.
      Ob der eigentliche Inhalt bösartig ist, ist letztlich eine Sache zwischen Entwicklern und Nutzern.
      Wenn andere Distributionen den gegenteiligen Eindruck erweckt haben, halte ich das eher für irreführend.
      Die Ausnahme, die mir einfällt, ist Tails, aber Tails ist nicht so breit aufgestellt wie Nix.
    • Ich frage mich, welche Distributionen das so machen.
      Soweit ich sehe, tut Debian das nicht mehr; dort signiert das Build-System den Build. Fedora macht es ebenfalls nicht, und bei Arch bin ich mir nicht sicher, glaube aber auch nicht.
      Das NixOS-Build-System signiert alle Build-Artefakte mit seinem eigenen Schlüssel und verifiziert die Signaturen beim Download.
      Wenn man paranoid herangeht, macht Nix es immerhin einfach, alles direkt aus dem Quellcode zu bauen.

  • Ein sehr beeindruckender Meilenstein, Glückwunsch an alle, die das möglich gemacht haben.
    Beim tatsächlichen Neubauen des ISO gab es ebenfalls Unterschiede; als Ursachen werden verbleibende Probleme im Hydra-Cache und die Art der ISO-Erzeugung genannt.
    Ich frage mich, ob jemand erklären kann, wie „die Art, wie das ISO erzeugt wurde“, behoben wurde.
    Ich hatte früher versucht, reproduzierbare ISOs zu erstellen, konnte das Dateisystem aber nicht dazu bringen, Extents deterministisch zu erzeugen.

    • Für NixOS steht das im Abschnitt „Wie haben wir es reproduziert?“ des Artikels.
      Der letzte Schritt dieses Prozesses erzeugt das ISO im Verzeichnis ./result/iso.
      Gesucht ist vermutlich der Befehl, den dieser Build aufgerufen hat, aber ich bin mir nicht ganz sicher, welchen Schritt du meinst.
      Der xorriso-Aufruf steht zum Beispiel hier: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-...

  • Muss man dafür nicht die Systemzeit fälschen?
    Zeit landet auf die eine oder andere Weise häufig in Binärdateien.

    • Tatsächlich sind Timestamps wahrscheinlich eine der häufigsten Ursachen für Nichtdeterminismus.
      Das ist so verbreitet, dass viele Compiler eine De-facto-Standardvariable zum Fälschen von Timestamps implementiert haben: SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/
    • Ich würde gern Beispiele sehen, auf welche Weise und aus welchen Gründen so etwas passiert.
    • Man kann Timestamps in allen Builds einfach gar nicht einbetten oder sie auf 0 setzen, sodass das Build-Datum überall 1970 ist.

  • Hilft das nicht dabei, das Problem zu lösen, über das Ken Thompson in „Reflections on Trusting Trust“ geschrieben hat?
    Wenn man das gesamte System vollständig aus dem Quellcode bootstrappen kann, dürfte es schwieriger werden, so etwas wie einen Compiler mit eingebauter Backdoor einzuschleusen.

    • Es hilft tatsächlich, ist aber keine vollständige „Lösung“.
      Theoretisch könnte es in der Umgebung, in der das ISO gebaut wird, eine ausgeklügelte Backdoor geben.
      Wenn man dieses Problem wirklich lösen möchte, kann man sich Diverse Double Compiling (https://dwheeler.com/trusting-trust/) oder das Bootstrapping der gesamten Umgebung (https://bootstrappable.org/) ansehen.
      Auch der Abschnitt „Gibt es beim obigen Ansatz kein Bootstrap-Problem?“ im Artikel ist relevant.
      Trotzdem trägt allein das Reproduzieren des Builds schon viel dazu bei, solche Angriffe immer unwahrscheinlicher zu machen.

  • Wegen meiner jüngsten Arbeit war ich im Red-Hat-Ökosystem unterwegs.
    Ich frage mich, wie sich das mit Dingen wie Fedora Silverblue, Ansible oder Fedora Silverblue + Ansible vergleicht.

    • Im Fedora-Ökosystem kommt osbuild / imagebuilder dem NixOS-ISO-Builder und dessen Reproduzierbarkeit am nächsten: https://www.osbuild.org/guides/introduction.html
      Imagebuilder beansprucht Reproduzierbarkeit, installiert meines Wissens aber die meisten rpm-Pakete als Binärpakete und nicht aus dem Quellcode.
      Wenn also nicht auch alle Eingabepakete reproduzierbar sind, ist es streng genommen keine Reproduzierbarkeit.
      Wenn die Erklärungen zum Bauen von Paketen aus dem Quellcode, zum Erstellen von Distributions-Images und zum Umgang mit Reproduzierbarkeit nicht wirklich bei dir angekommen sind, gehörst du wahrscheinlich nicht zur Hauptzielgruppe.
    • Nix ist ein deklaratives OS: Man beschreibt, wie das OS aussehen soll.
      Ansible hingegen gibt die Schritte vor, denen das OS folgen soll.

Silverblue und Nix sind, abgesehen davon, dass beide Linux-Distributionen sind, orthogonal zueinander
Silverblue ist der Versuch, die Art der Softwarebereitstellung zu ändern, indem auf einem unveränderlichen Host nur Container verwendet werden
Wenn man nach einer Ansible-Alternative sucht, die Nix mit Jsonnet und Zustandsverfolgung ein Stück weit nachahmt, ist Etcha einen Blick wert: https://etcha.dev

  • Ansible wendet veränderliche Änderungen in Arbeitseinheiten auf das OS an
    Nix ist unveränderlich
    Neue Änderungen werden vollständig neu erzeugt, und erst nach erfolgreichem Build werden alle Pakete in das aktuelle System „symbolisch verlinkt“
    Fedora Silverblue basiert auf ostree https://github.com/ostreedev/ostree
    Es verhält sich für den Root-Tree ähnlich wie git, aber um Änderungen anzuwenden, muss das gesamte System neu gestartet werden
    Da Nix Pakete per symbolischem Link einbindet, muss das System nicht neu gestartet werden
    Eine ausführlichere Erklärung gibt es hier: https://dataswamp.org/~solene/2023-07-12-intro-to-immutable-...