Reproduzierbarer Build

Ein reproduzierbarer Build liefert bitgenau identische Ergebnisse, wann immer jemand denselben Quellcode mit derselben Build-Umgebung und denselben Build-Anweisungen baut. So lautet die Definition des Projekts Reproducible Builds. Ergebnis meint hier die Artefakte, um die es beim Build geht: ausführbare Dateien, Distributionspakete, Container- oder Dateisystem-Images. Logs zählen nicht. „Es baut wieder“ ist nicht dasselbe; reproduzierbar heißt, dass die Bytes übereinstimmen.

Warum die meisten Builds nicht reproduzierbar sind

• Auflösung der Abhängigkeiten zur Build-Zeit. Ohne Lockfile wählt ein Paketmanager die Versionen, wenn der Build läuft. Die Auflösung bei PyPI kann je nach Reihenfolge der eintreffenden Antworten anders ausgehen, ein Versionsbereich verschiebt sich, sobald ein neues Release erscheint, und ein veränderlicher Tag wie latest zeigt plötzlich woandershin.
• Die Umgebung. Zeitstempel, Dateipfade, die Locale und die eigenen Tools des Hosts landen in den Artefakten.
• Zufall. Build-Schritte können IDs erzeugen, Dateien nach Hash sortieren oder Arbeit parallel in jedes Mal anderer Reihenfolge ausführen.

Denselben Commit zweimal hintereinander zu bauen, garantiert also weder dasselbe Ergebnis noch dieselbe SBOM. Ein Build, der Code lädt, den sein Lockfile nicht aufführt, eine versteckte Abhängigkeit, macht es noch schlimmer.

Wie Teams Builds reproduzierbar machen

• Pinnen und sperren Sie jede Eingabe, auch Basis-Images per Digest und Tools per Version (siehe Lockfile).
• Nutzen Sie eine feste Zeit statt der Uhr: SOURCE_DATE_EPOCH ist eine standardisierte Umgebungsvariable mit einem Unix-Zeitstempel, den Build-Tools anstelle der aktuellen Zeit verwenden.
• Entfernen oder normalisieren Sie Build-Pfade, sortieren Sie Dateilisten und legen Sie die Locale fest.
• Bauen Sie in einer hermetischen Umgebung, deren Toolchain selbst gepinnt ist. Nix ist ein Weg dazu.
• Prüfen Sie es: Bauen Sie denselben Commit zweimal unabhängig voneinander (auf einer anderen Maschine, in einem anderen Pfad, an einem anderen Tag) und vergleichen Sie die Ergebnisse. Wo die Hashes abweichen, zeigt diffoscope genau, was sich unterscheidet.

Das Yocto Project zeigt, warum Reproduzierbarkeit eine Eigenschaft ist, die man prüfen muss, statt sie anzunehmen. Seine Dokumentation sagt, dass die Builds des Projekts seit Release 3.1 „bis auf Binärebene einschließlich Zeitstempeln“ reproduzierbar sind, dass nur BitBake und OpenEmbedded-Core vollständige Reproduzierbarkeit garantieren und dass „diese Garantie erlischt, sobald Sie einen weiteren Layer hinzufügen“. Das Projekt testet das mit oe-selftest.

Reproduzierbare Builds und SBOMs

Wäre jeder Build reproduzierbar, könnten Sie ein altes Release später neu bauen und seine SBOM erzeugen. Die meisten sind es nicht, also beschreibt ein Neubau oder ein heutiger Scan des Quellcodes einen ähnlichen Build, nicht den, den Sie ausgeliefert haben. Was in Produktion ist, zeigt die SBOM, die im CI-Build des Releases aufgezeichnet wurde.

Selbst ein reproduzierbarer Build macht diese Aufzeichnung nicht überflüssig. Übereinstimmende Hashes beweisen, dass zwei Builds dasselbe Ergebnis erzeugt haben; sie listen nicht auf, was hineingeflossen ist. Sie brauchen weiterhin das Inventar und eine ehrliche Angabe seiner SBOM-Vollständigkeit. Warum CI der Ort für Supply-Chain-Sicherheit ist und SBOM Best Practices führen das Argument ausführlicher aus.

SLSA behandelt Reproduzierbarkeit als eine Möglichkeit, zu prüfen, ob ein Build getan hat, was er vorgibt.

Reproduzierbarkeit erreichen Teams in ihrem Build-System, mit Werkzeugen wie Nix, Yocto oder den Tools von Debian. CRACI macht Builds nicht reproduzierbar: Es zeichnet die SBOM jedes Builds während des Builds auf, sodass der Nachweis dessen, was ausgeliefert wurde, nicht von einem Neubau abhängt. Siehe Build-Time-SBOMs.