Pakete zweimal bauen und vergleichen

Zurzeit testen die Debian-Entwickler auf einem Testserver, wie sehr sich Pakete unterscheiden, wenn sie zweimal hintereinander mit denselben Optionen gebaut werden. Die Pakete unterscheiden sich dabei in vielen Details, das häufigste Problem sind Timestamps, die in den verschiedensten Dateiformaten mitgespeichert werden. Dazu kommt die Reihenfolge von Dateien, aber auch subtile Probleme, etwa Compile-Prozesse, die je nach CPU-Auslastung zu anderen Ergebnissen kommen.

In den bisherigen Tests können bereits 81,7 Prozent der Debian-Pakete reproduzierbar gebaut werden. Das ist laut Holger Levsen schon ein großer Erfolg und war mit viel Arbeit verbunden. Doch der aktuelle Test hat einige Nachteile. So werden die Pakete immer auf derselben CPU und mit demselben Kernel gebaut. Ein künftig geplanter Test, in dem die Pakete auf unterschiedlichen Systemen gebaut werden, dürfte noch einige weitere Unterschiede zutage bringen. Statistiken über die Ergebnisse der Build-Prozesse können alle unter der URL reproducible.debian.net abgerufen werden.

Nichtdeterminismen können auch Privacy-Problem sein

Lunar erwähnte einige Beispiele, bei denen die in Dateien gespeicherten Informationen durchaus ein Privacy-Problem darstellen können. Dazu gehören beispielsweise Hostnamen, Benutzernamen, Pfade des Build-Prozesses oder Spracheinstellungen des Systems, die auf die ein oder andere Art in einem späteren Paket landen können. Reproduzierbare Builds sind also nicht nur aus Sicherheitsgründen sinnvoll, sie können auch zum Schutz der Privatsphäre der Entwickler beitragen.

Einige besonders exotische und unerwartete Beispiele kamen in der folgenden Diskussion ebenfalls zur Sprache. So speichern OGG-Dateien eine zufällig generierte Seriennummer, ein Kommentar aus dem Publikum merkte an, dass der GCC die Wahl bestimmter Hash-Funktionen von der aktuellen CPU abhängig macht. Die Krypto-Bibliothek NaCl nutzt automatische Benchmarks, um von verschiedenen Implementierungen eines Algorithmus den schnellsten auszuwählen. Laut Lunar sind es überraschenderweise in vielen Fällen nicht die kompilierten Dateien selbst, die die meisten Probleme machen, sondern die mitgelieferte Dokumentation, die in verschiedensten Dateiformaten ausgeliefert wird.

Das nächste Ziel des Projekts: Die übernächste Debian-Version Stretch soll reproduzierbare Build-Prozesse integrieren. Da einige Debian-Entwickler im Saal waren, fragte Levsen sie, ob irgendjemand dagegen sei, dies in Stretch zu implementieren. Niemand meldete sich. Levsen und Lunar riefen die Anwesenden dazu auf, sich an der weiteren Entwicklung von reproduzierbaren Builds zu beteiligen. Dafür gibt es Mailinglisten, einen IRC-Chat #debian-reproducible im OFTC-Netz und eine Wiki-Seite.

Binärtransparenz und Cross-Compiles

Für die Zukunft gibt es noch einige weitere Pläne, um das Vertrauen zusätzlich zu stärken. Der Debian-Entwickler Daniel Kahn Gillmore arbeitet an einem System zur Binärtransparenz. Die Idee dabei ist es, in einem öffentlich verifizierbaren Log, das ähnlich wie die Bitcoin-Blockchain oder Certificate Transparency funktioniert, Checksummen aller Binärpakete abzuspeichern. Damit könnte garantiert werden, dass alle Nutzer eines Systems dieselben Binärpakete erhalten. Ein weiteres Ziel: die Reproduzierbarkeit über Cross-Compiles auf unterschiedlichen Architekturen. Dadurch wäre gewährleistet, dass selbst eine Backdoor im Binärcode des Compilers nicht mehr unentdeckt bleiben könnte.

Neben Debian haben auch Entwickler bei Fedora und bei NixOS Interesse an reproduzierbaren Build-Prozessen. Die Debian-Entwickler hoffen besonders auf die Hilfe von Fedora, doch offenbar gab es dort außer einem Blogbeitrag bislang keine weitere Aktivität in dieser Richtung. Opensuse liefert immerhin schon ein Tool namens build-compare mit, welches Unterschiede zwischen verschiedenen Builds anzeigt. Die Hoffnung von Holger Levsen und Lunar: Künftig sollten reproduzierbare Builds der Normalfall werden. Ein großes Ziel - für mehr Sicherheit und Vertrauenswürdigkeit in die Software, die wir tagtäglich benutzen.