Unsere Build- und Release-Infrastruktur sowie anstehende Neuerungen

Hinter den Kulissen von F-Droid gibt es einen riesigen Haufen an Automation, um den Herstellungsvorgang tausender Apps aus dem Quellcode zu steuern. Das bedeutet die Untersuchung tausender Quellcode-Repos, ihre Überprüfung auf Aktualisierungen, Herstellung und neue Veröffentlichungen sowie deren massenhafte sichere Signierung. Alle Builds laufen in einer frischen Gastinstanz einer virtuellen Maschine, bekannt als buildserver. Alle Gradle-Binärdateien und Android-SDK-Pakete werden gegen unsere öffentlichen Logs überwachter SHA-256-Checksums abgeglichen. Die transparenten Protokolle überprüfen auch die öffentlichen Checksums des Upstreams.

Unsere Einrichtungen laufen fast ausschließlich auf Debian. Debian ist ein Anführer bei freier Software, felsenfesten Servern und reprozierbaren Builds. Das macht es zur natürlichen Heimat für F-Droid. Wir arbeiten auch daran sicherzustellen, dass die Pakete, die wir nutzen, und unsere Prozesse auf Debian-Paketen aufbauen. Das heißt, wir teilen uns die Wartung mit allem, was Debian verwendet. Es mag so erscheinen, als brächte dies Mehrarbeit, aber unserer Erfahrung nach zahlt sich das auf lange Sicht aus. So ist die F-Droid-Community in der Lage, viele Dinge mit einem kleinen Team zu pflegen. Ein weiteres Beispiel dazu ist diese Internetseite selbst: sie wird mittels Jekyll-Paketen aufgebaut, die alle in Debian sind.

Wenn ihr eine App auf f-droid.org habt, habt ihr vielleicht bemerkt, dass ale Builds auf einer 5 Jahre alten Debian-Version stretch geschehen. Wir sind aktuell mitten in einem großen Versuch ein Upgrade auf die neuste Version bullseye zu starten. Das ist nicht gerade ein einfaches apt-get upgrade, wir ergreifen auch diese Gelegenheit, den Build-Vorgang zu überholen, damit App-Builds auf einer relativ geradlinigen Debian-Installation als Basis-OS funktionieren. Wir müssen eine Plattform bereitstellen, um tausende Apps herzustellen, so können wir nicht einfach das Basis-Image beliebig oft upgraden. Einige Apps benötigen das neuste, beste. Andere Apps brauchen das altertümliche, stabile Basis-OS. Diese Änderung bedeutet, dass die Metadaten soviel wie möglich der Build-Logik enthalten, so dass die App-Maintainer die Kontrolle über alle Schritte haben. Um dies zu erzielen, wird so viel wie möglich aus dem Basis-Image des buildserver abgezogen.

Wir haben überlegt, eine Auswahl an Basis-Images anzubieten. Das ist eine mögliche Lösung, aber es ist nicht leicht so einfach jedes verfügbare Docker-Image zu nutzen. Nur Basis-Images, die garantiert freie Software sind, sind dafür geeignet. Einfach auf jedes Docker-Image zu verweisen, würde Möglichkeiten für proprietäre Build-Abhängigkeiten eröffnen, da es nicht möglich ist, automatisch zu prüfen, ob ein Docker-Image zu 100 % freie Software ist. Die Verwendung einer Auswahl an vorab freigegebenen Basisausstattungen könnte das lösen. Behaltet im Auge, das ist komplizierter als bei GNU/Linux-Distros, da Android-Apps plattformübergreifend kompiliert werden. GNU/Linux-Distros stellen ihre Pakete in ihrem eigenen OS her. Während Builds, erlaubt Debian nicht einmal den Netzwerkzugriff, da alle Abhängigkeiten aus Debian-Paketen kommen müssen. Dieses Verifizierungsniveau ist ein Ziel von F-Droid und die Arbeit von Maven in Richtung eines reproduzierbaren Maven Central-Ökosystems hift dabei eine Menge.

Nachdem CalyxOS standardmäßig auf F-Droid baut, möchte das Calyx Institute auch sicherstellen, dass F-Droid läuft wie geschmiert und dass die App-Entwickler glücklich sind. Ich darf mich beim Calyx Institute dafür bedanken, das es 42 Stunden meiner Zeit im Monat finanziert, um daran zu arbeiten, die Abläufe in unserer Build-Infrastruktur reibungslos zu gestalten. Nebenbei werde ich daran arbeiten, die Automation des Signiervorgangs zu verbessern. Unser Signierprozess läuft momentan 100% offline. Während das für die Sicherheit schön ist, verlangsamt es den Freigabeprozess. Mit modernen Hardware-Sicherheitsmodulen und Server-Einrichtungen ist es möglich, gute Sicherheit zu erzielen, ohne zu 100% offline zu sein. Haben wir eine Automatisierung der Signierung, eröffnet das dann Möglichkeiten, den kompletten Prozess zu parallelisieren, das beinhaltet, dass multiple App-Builds laufen und auch dass die Hauptschritte Herstellung, Indexerzeugung und Signierung alle parallel laufen. Diese Arbeit wird schrittweise ausgerollt, sobald jedes Bit fertig ist. Habt also ein wenig Geduld und ihr werdet feststellen, dass Releases schneller und schneller geschehen werden!