- Fedora treibt in Fedora 43 eine Änderung voran, um 99 % aller Pakete reproduzierbar zu machen
- Durch Verbesserungen an der bestehenden Infrastruktur wurden bereits 90 % erreicht; für den Rest sollen Paketbetreuer dazu gebracht werden, die Probleme als Bugs zu erkennen und zu beheben
- Ziel sind stärkere Sicherheit und höhere Paketqualität; außerdem soll das unabhängige Verifizierungswerkzeug
rebuilderd eingeführt werden
Überblick über reproduzierbare Builds im Open-Source-Bereich
- Um die Sicherheit von Open-Source-Software zu stärken und ihre Integrität zu verifizieren, werden reproduzierbare Builds immer wichtiger
- Ein reproduzierbarer Build ist ein Build, bei dem mit demselben Quellcode, derselben Build-Umgebung und denselben Build-Befehlen von jedem dasselbe Ergebnis erzeugt werden kann
- Debian ist in diesem Bereich seit mehr als 10 Jahren voraus und kann inzwischen sogar offizielle Live-CDs reproduzierbar erstellen
- Fedora hat mit der Arbeit an reproduzierbaren Builds erst vor Kurzem begonnen, prüft aber nun einen Vorschlag, im Entwicklungszyklus von Fedora 43 99 % aller Pakete reproduzierbar zu machen
Unterschiede zwischen Fedora und Debian
- Debian erlaubt das Hochladen lokal gebauter Pakete, was die Vertrauenswürdigkeit senken kann
- Fedora baut alle Pakete zentral in einer stark kontrollierten Infrastruktur
- Fedora nutzt ein Git-Repository namens
dist-git, das Quell- und Hash-Informationen enthält und die Nachverfolgung von Paketen erleichtert
Fedoras eigene Definition reproduzierbarer Builds
- Fedora verwendet eine andere Definition als Debian
- Signaturen (
signature) und einige Metadaten werden ausgenommen; der Fokus liegt auf dem eigentlichen Inhalt (payload) der RPM-Datei
- Der Grund liegt in den Eigenschaften des RPM-Formats und der Signaturmethode sowie darin, dass Informationen wie Build-Zeit (
BUILDTIME) und Build-Host (BUILDHOST) enthalten sind
- openSUSE löst das Problem, indem
BUILDHOST auf reproducible gesetzt wird
Technischer Fortschritt auf dem Weg zu reproduzierbaren Builds in Fedora
- Seit Fedora 38 wurde eine Änderung eingeführt, die mit
SOURCE_DATE_EPOCH die Änderungszeit von Dateien festschreibt
- In Fedora 41 wurde das Rust-basierte Werkzeug
add-determinism eingeführt, das die Metadaten erzeugter Dateien standardisiert
- Debian verwendet die Perl-Bibliothek
strip-nondeterminism, Fedora entschied sich jedoch für ein eigenes Werkzeug, um Perl-Abhängigkeiten zu vermeiden
- Bisher wurde bei rund 90 % der Pakete Reproduzierbarkeit erreicht
Nächste Pläne
- Bei den verbleibenden 9 % sollen Paketbetreuer dazu gebracht werden, Probleme mit fehlender Reproduzierbarkeit als Bugs zu behandeln und zu beheben
- Mit dem Werkzeug
fedora-repro-build soll lokal getestet werden können, ob ein Koji-Build reproduzierbar ist
- Ein unabhängiges Verifizierungssystem namens
rebuilderd soll öffentlich betrieben werden; es analysiert Paketmetadaten und überprüft die Reproduzierbarkeit durch Neu-Builds
rebuilderd kann mit diffoscope Berichte über Unterschiede erzeugen
Packaging-Richtlinien und Qualitätsverbesserung
- Fedoras Packaging-Richtlinien sollen auf „sollten, wenn möglich, reproduzierbar gebaut werden“ aktualisiert werden
- Reproduzierbare Builds tragen nicht nur zur Sicherheit bei, sondern verbessern auch die Paketqualität
- Beispiel: Wenn in einem architekturunabhängigen Paket Hardware-Abhängigkeiten gefunden werden, ist das wahrscheinlich ein Bug
Ausnahmefälle ohne Reproduzierbarkeit
- Haskell ist bei Multithread-Builds nicht reproduzierbar; an einer Korrektur wird gearbeitet
- Go ist wegen inkonsistenter Debug-Dateien
.gdb_index nicht reproduzierbar; es gibt noch keine Lösung
- Bei Linux-Kernelmodul-Signaturen werden temporäre Schlüssel verwendet; ein entsprechender Patch wurde vorgeschlagen
Feedback aus der Community
- Im Fedora-Infrastrukturteam wurden Fragen zum Standort und zur Wartung von
rebuilderd aufgeworfen
- Diskutiert wurde auch, ob sich
rebuilderd in Koji integrieren lässt
- Es gibt zudem die Ansicht, dass für eine unabhängige Verifizierung ein System außerhalb von Koji wünschenswert ist
- Einige schlugen außerdem vor, statt
rebuilderd Copr zu nutzen
- Insgesamt wird eine Richtung bevorzugt, die die Integration mit bestehenden Fedora-Werkzeugen verbessert
Weiteres Vorgehen
- Ein Vorschlags-Ticket soll bei FESCo (Fedora Engineering Steering Committee) eingereicht werden
- Bei einer Genehmigung sollen die Umsetzungsarbeiten bis zum für Oktober geplanten Release von Fedora 43 deutlich intensiviert werden
- Endnutzer werden den Unterschied vermutlich kaum bemerken, aber für die Sicherheit der Lieferkette ist dies eine sehr wertvolle Änderung
7 Kommentare
Das Fedora-Team ist immer beeindruckend, und ich habe das Gefühl, dass sich die meisten Entscheidungen in die richtige Richtung entwickeln. Ich nutze es jedes Mal mit Dankbarkeit gegenüber allen, die dazu beitragen.
Früher wurde das wohl oft genutzt, aber warum ist es heutzutage in Vergessenheit geraten?
In der Linux-Community ist es für Linux-Desktops nach wie vor sehr beliebt.
Da es keine Distribution für den Servereinsatz ist, scheint es in unserem Land, wo Linux-Desktops nicht besonders verbreitet sind, nicht sonderlich bekannt zu sein.
Aha, wenn man heutzutage kein Heavy User ist, scheint man sich eher für Ubuntu zu entscheiden, weil es sich sowohl für Server als auch für den Desktop eignet!
Irgendwie freue ich mich immer, wenn es um Linux geht, deshalb wollte ich auch noch etwas dazu sagen.. hehe
Bei Ubuntu ist seit der Einführung von Snap die Stimmung im Desktop-Lager regelrecht abgestürzt, und auch die Unity-DE polarisiert stark.. Außerdem ist der Release-Zyklus zu lang, sodass aktuelle Treiber oft nicht gut unterstützt werden..
Wenn ihr Desktop-Linux in Betracht zieht, kann ich Fedora wirklich empfehlen.
Fedora verwendet ein GNOME, das sehr nah am Original ist, und auch GNOME hat in letzter Zeit richtig starke Updates bekommen, deshalb bin ich damit wirklich sehr zufrieden!
Vielen Dank, haha
Wenn ich an Fedora denke, kommen alte Erinnerungen hoch
Hacker-News-Kommentare
gcc-Compiler unterstützt keine Multithread-Kompilierung. Bei C kommt Parallelisierung daher, dass mehrere Übersetzungseinheiten parallel kompiliert werden