Vertrauen ist gut, Kontrolle ist besser
Reproduzierbarkeit bei F-Droid
Verfasst von Nico Alt (CC BY-NC-SA 4.0)
There’s also an English version. También hay una traducción a Español.
Freie Software ist toll, denn damit können Nutzer überprüfen, ob eine App auch wirklich das macht, was sie verspricht. Doch die wenigsten Nutzer bauen sich ihre Programme aus dem Quellcode selbst. Stattdessen werden fast immer fertig gebaute Apps verwendet, die bei Google Play und Apples App Store vom Entwickler und bei F-Droid vom Projekt selber kommen. In allen drei Fällen muss man als Nutzer darauf vertrauen, dass in der App auch wirklich nur das enthalten ist, was im Quellcode der App steht. Es ist jedoch keine Schwierigkeit, während des Bauprozesses Modifikationen an der App vorzunehmen, die nirgendwo dokumentiert sind. An genau dieser Stelle setzt das Konzept der Reproduzierbarkeit (reproducible builds) an. Ist eine App reproduzierbar gebaut, kann jeder überprüfen, ob an der App während des Baues herumgewerkelt oder ob sie direkt aus dem Quellcode gebaut wurde. Nutzer müssen dann nicht mehr nur dem Entwickler oder F-Droid vertrauen, wenn sie Apps aus deren Haus installieren. Stattdessen kann jeder, der dazu gewillt ist, selbst probieren, die App zu reproduzieren.
Das Ziel der Reproduzierbarkeit ist es, einen verifizierbaren Weg vom Quellcode zur Binärdatei zu schaffen, also zu der Datei, die später auf dem Gerät des Nutzers installiert wird. Entgegen der intuitiven Vorstellung ist es meistens nicht der Fall, dass aus ein und dem selben Quellcode nach dem Bau die exakt gleiche Binärdatei herauskommt. Stattdessen kommt es immer wieder zu kleinen, für den Ablauf des Programms irrelevanten Änderungen einzelner Teile, die eine Überprüfung der Binärdatei unmöglich machen. Wenn man Glück hat, reicht es, die Versionen der Build-Tools anzugeben, mit denen die App gebaut wurde, um anderen zu ermöglichen, die App zu reproduzieren. Es können aber auch Probleme auftreten, die nicht so einfach zu lösen sind.
In der Vergangenheit spielte das Thema Reproduzierbarkeit in der Software-Entwicklung keine große Rolle. Erst seit einigen Jahren gibt es vor allem im Bereich der Freien Software Bestrebungen, Software reproduzierbar zu bauen, denn daraus ergeben sich viele neue Möglichkeiten. So muss zum Beispiel dem Bau-Server nicht mehr vollständig vertraut werden und es ist viel einfacher, gespendete Rechenpower von Dritten zu verwenden. F-Droid ist dafür ein gutes Beispiel: Im Gegensatz zu den großen, kommerziellen App Stores werden bei F-Droid nur Apps angeboten, deren Quellcode unter einer freien Lizenz veröffentlicht ist und die somit Freie Software sind. Um zu verhindern, dass Entwickler Änderungen an den Apps vornehmen können, die nicht im Quellcode dokumentiert sind, werden bei F-Droid seit dessen Gründung vor bald neun Jahren alle Apps vom Projekt selber gebaut. Das ist gleichzeitig die größte Stärke als auch der größte Schwachpunkt des Projekts: Weil wirklich jede App von F-Droid gebaut und signiert wird, unterliegt der Bau-Server von F-Droid hohen Sicherheitsauflagen und nur der Gründer Ciaran Gultnieks hat Zugriff auf diesen. Dieser zentrale und wichtige Punkt innerhalb der F-Droid-Infrastruktur ist damit ihr größter Flaschenhals und immer wieder kommt es zu Verzögerungen bei Updates.
Auf diesem Teilausschnitt eines diffoscope-Vergleiches der App OsmAnd~ ist zu sehen, wie in früheren Versionen des F-Droid-Servers ein Hash eingefügt wurde, der die Reproduzierbarkeit der App unmöglich machte. Außerdem ist auf der rechten Seite zu sehen, wie Informationen über die verwendeten Build-Tools hinzugefügt wurden.
Es gibt Pläne, die diese Situation drastisch verbessern würden, und alle beinhalten Reproduzierbarkeit als zentralen Dreh- und Angelpunkt im Kern. Eine Möglichkeit, die sofort umsetzbar ist und schnellere Updates für einzelne Apps verspricht, wurde von dem Autor dieses Textes der alternativen YouTube-App NewPipe vorgeschlagen, die diese Idee in den nächsten Monaten umsetzen möchte. Die Grundidee ist wie folgt: Wenn eine App reproduzierbar gebaut ist, kann F-Droid die offizielle, vom Entwickler signierte APK-Datei direkt im Store einbinden. Wenn es nun wieder zu Verzögerungen bei Aktualisierungen kommt, kann der Entwickler den Nutzern in der App eine Benachrichtigung schicken, die es ihnen erlaubt, auf die neue Version der App zu aktualisieren, obwohl diese noch gar nicht im F-Droid-Store enthalten ist. Dies funktioniert, da der Nutzer die vom Entwickler signierte App installiert hat und somit nicht auf F-Droid warten muss, bis die neue Version auch dort enthalten ist. Der andere, eher mittel- bis langfristige Plan ist, die Bau-Infrastruktur von F-Droid komplett zu dezentralisieren. Kann der Großteil der Apps reproduzierbar gebaut werden, können mehr F-Droid-Unterstützer mehr Rechenpower verwenden, um Apps zu reproduzieren und Erfolg oder Misserfolg öffentlich zu verkünden. Einigen sich genügend offizielle Server darauf, dass eine App reproduzierbar aus dem offiziellen Quellcode gebaut wurde, kann diese direkt in den F-Droid-Store eingebunden werden, ohne auf den zur Zeit noch einzigen Bau-Server warten zu müssen. So könnte bald auch eine App in den Store einziehen, die schon von vielen F-Droid-Nutzern genutzt wird, aber aufgrund von Vorgaben des Herstellers derzeit dort nicht verfügbar ist: Signal. Der Instant-Messenger ist trotz mehrerer Versuche, ihn neben Google Play auch über F-Droid zu vertreiben, seit seiner Umbenennung vom Vorgänger TextSecure zum heutigen Namen Signal nicht mehr in F-Droid enthalten. Der Hersteller hinter der App verbietet es, andere Binärdateien als die von ihm signierten zu veröffentlichen, und so sind Nutzer bisher darauf angewiesen, dem Hersteller zu vertrauen, dass in der offiziellen App-Version keine Hintertüren eingebaut wurden. Wäre Signal reproduzierbar gebaut, könnte dies jeder und damit auch F-Droid überprüfen und anschließend in seinen Store einbinden. Die Infrastruktur dafür bietet F-Droid mittlerweile. Nun liegt es an Signal, die App reproduzierbar zu machen.
Mit der App Checkey lassen sich Details zu den Signaturen installierter Apps anzeigen. Man sieht, dass die App Transportr von F-Droid signiert wurde (CN=FDroid), während bei Briar die von den Entwicklern signierte App in den Store eingebunden wurde (O=briarproject.org).
Als Nutzer zu sehen, ob eine App reproduzierbar gebaut ist oder nicht, ist noch nicht ganz einfach. Da das Thema Reproduzierbarkeit erst in den letzten Jahren große Verbreitung gefunden hat, besteht noch keine einheitliche Meinung darüber, wie man den Status einer App am besten kennzeichnen sollte. Im Moment sind in F-Droid noch relativ wenige Apps reproduzierbar gebaut, weshalb eine Warnung vor fehlender Reproduzierbarkeit zwangsläufig an vielen Stellen weggeklickt werden müsste. Um das Thema nicht zu “verbrennen”, wurde so entschieden, erst einmal keinerlei Informationen über die Reproduzierbarkeit in F-Droid selbst anzuzeigen, und sich stattdessen das Thema für die Zukunft aufzuheben, wenn Reproduzierbarkeit mehr Verbreitung gewonnen hat und bedeutend mehr Apps reproduzierbar gebaut sind. Für Nutzer, die trotzdem an diesem Thema interessiert sind, bieten sich zwei Möglichkeiten an. Zuerst gibt es die App Checkey, mit der sich Informationen zu den Signaturen installierter Apps anzeigen lassen. Derzeit sind die meisten Apps im F-Droid-Store noch mit F-Droid-eigenen Zertifikaten signiert, was man an der Zeile “Issuer” erkennen kann, die dann die Werte “CN=FDroid […]” enthält. Lässt man sich hingegen die Signatur für eine reproduzierbar gebaute App anzeigen, ändert sich dieser Wert. Bei Briar wird so der Wert “O=briarproject.org” angezeigt. Eine andere Methode, mehr über die Reproduzierbarkeit einer App zu erfahren, ist der Besuch der Seite verification.f-droid.org. Dort werden in regelmäßigen Abständen alle Apps aus F-Droid nachgebaut und so überprüft, ob eine App reproduzierbar ist. Dort lässt sich leider nicht erkennen, ob bei Erfolg auch die originale APK-Datei des Entwicklers eingebunden wird. Denn auch wenn eine App schon reproduzierbar gebaut werden kann, bedeutet dies noch nicht, dass auch eine vom Entwickler signierte APK-Datei im F-Droid-Store angeboten wird. Dafür ist noch weitere Arbeit vonseiten der Entwickler nötig.
Doch auch außerhalb der Freien Software ist Reproduzierbarkeit ein wichtiges Thema. Genauso wie Entwickler Freier Software Ziel eines Angriffes werden können, kann es Hersteller proprietärer Software ([1], [2], [3]) treffen. So kam es in der Vergangenheit nicht selten vor, dass Firmen angegriffen wurden, indem Computersysteme mit Schadsoftware infiziert wurden, die dafür gesorgt hat, dass während des Bauprozesses Hintertüren in deren Software eingebaut wurden. Um Angriffe dieser Art zu erkennen und das Risiko zu verringern, Opfer einer solchen Attacke zu werden, kommt man um das Thema Reproduzierbarkeit nicht drumherum. So kann man den Quellcode von mehreren, voneinander unabhängigen Bau-Servern kompilieren lassen und das Endergebnis vergleichen. Wenn alle Server die exakt gleiche Datei produzieren, kann man mit hoher Wahrscheinlichkeit sagen, dass die Binärdatei frei von Hintertüren ist. Natürlich gilt dies nur, wenn auch der Quellcode keine Lücken enthält. Reproduzierbarkeit ersetzt also nicht die schon seit vielen Jahren praktizierten Sicherheitsmaßnahmen wie Pentesting und Code Reviews, sondern erweitert diese. Ein ganz anderes Anwendungsfeld sind Delta Updates. Bei dieser speziellen Form von Aktualisierungen wird nicht die komplette Datei als Update heruntergeladen, sondern nur die Differenz, die zwischen zwei Versionen besteht. Delta Updates werden bei Android schon seit einiger Zeit eingesetzt und auch unter Windows ist diese Form schon seit XP unter dem Namen “Express-Installationsdateien” bekannt. Ist ein Programm nicht reproduzierbar, gibt es bei jedem Bau kleine Änderungen, die bei einem Delta Update die Gesamtgröße des Updates unnötigerweise vergrößern. Aus unter anderem diesem Grund hat auch Google ein Interesse daran, dass Apps unter Android reproduzierbar gebaut werden können, und hat deshalb ein zentrales Problem gelöst, das dies in der Vergangenheit verhindert hat.
Bis zur Version 3.0.1 des Gradle-Plugins war es unter Android kein Problem, Apps reproduzierbar zu bauen. Doch mit darauffolgenden Versionen war es nicht mehr möglich, Apps auf verschiedenen Computern zu reproduzieren, da sich immer wieder kleine Änderungen in die Datei resources.arsc einschlichen. Der Briar-Entwickler Torsten Grote meldete diesen Fehler im Juni 2018 an Google, als er versuchte, den Darknet-Messenger als erste reproduzierbar gebaute App in den F-Droid-Store zu bringen. Die bekannte Busfahrplan-App Öffi konnte dann im August vergangenen Jahres als erste reproduzierbar gebaute App in den F-Droid-Store einziehen, da sie eine ältere Version des Gradle-Plugins nutzte. Drei Monate später, im November 2018, fand auch Briar seinen Weg in F-Droid, da es Grote gelang, den Fehler zu umgehen, indem er ein spezielles Dateisystem namens disorderfs einsetzte. Im Februar dieses Jahres vermeldeten Google-Entwickler schließlich, dass der Fehler gelöst sei und in den nächsten Versionen des Gradle-Plugins 3.4 und 3.5 erscheinen solle. Es bleibt zu hoffen, dass mit den neuen Versionen mehr reproduzierbar gebaute Apps ihren Weg in den F-Droid-Store finden werden.
Reproduzierbarkeit ist mittlerweile ein Thema, mit dem sich viele verschiedene Projekte beschäftigen. So arbeiteten beispielsweise die Kryptowährung Bitcoin und das Tor-Projekt daran, ihre Installationsdateien reproduzierbar zu machen, und setzen dies heute konsequent um. Bei Bitcoin bauen so mehrere unabhängige Entwickler neue Versionen der Software und vergleichen die Resultate mit denen der anderen Entwickler. Stimmen diese überein, wird die Binärdatei von allen signiert und anschließend veröffentlicht. Jeder, der Interesse daran hat, findet auf den Seiten der genannten Projekte Anweisungen, wie er die Binärdateien der Projekte reproduzieren kann.
Ernüchternde Neuigkeiten gab es aus der Debian-Welt: Die neuste Version des Linux-Betriebssystems, genannt Buster, verfügt über einen eigentlich sehr hohen Anteil an reproduzierbar gebauter Software von über 90%, doch der Debian-Entwickler Holger Levsen vermeldete Anfang März, dass nur etwa 54% der offiziellen Installationsdateien von Debian reproduzierbar sein werden. Grund dafür sei, dass ein großer Teil der Softwarepakete gebaut wurde, als Verbesserungen im Bereich der Reproduzierbarkeit noch nicht in der Bau-Umgebung von Debian verfügbar waren. Es wird derzeit überlegt, alle Pakete erneut zu bauen und so den Prozentsatz zu erhöhen.
Ein Programm reproduzierbar zu bauen, ist nicht immer einfach und kann in manchen Fällen einiges an Zeit in Anspruch nehmen, doch der Aufwand lohnt sich. Bis in F-Droid der Großteil aller Apps reproduzierbar gebaut und möglichst viele von Entwicklern signierte Apps verbreitet werden, wird noch einige Zeit vergehen. Doch die Grundlagen sind gelegt und nun geht es vor allem darum, kleinere Fehler zu finden und mit Entwicklern zusammen an der Einbindung ihrer Versionen zu arbeiten.
Links
F-Droid-Dokumentation zum Verification Server
Wertvoll für alle, die F-Droid-Apps selbst reproduzieren wollen
F-Droid-Dokumentation zu Reproduzierbarkeit
Weitergehende Informationen für Interessierte
Vertrauen, Privatsphäre und Freie Software - F-Droid.org
Blogbeitrag von eighthave, in dem auch über Reproduzierbarkeit berichtet wird (englisch-sprachige Originalversion)