IzzyOnDroid

• Intro
• App-Listen
• Artikel
• Bücher
• Downloads
• App-Repo
• Impressum

Rückblick auf 2024 und Ausblick auf 2025: Reproducible Builds, Sicherheitsmaßnahmen, und mehr

Im Januar/Februar 2024 haben wir zusätzliche APK-Checks im IzzyOnDroid Repo etabliert. Ein neues Jahr beginnt, und es ist fünf Monate her, dass wir offiziell mit unseren Reproduzierbaren Builds live gegangen sind (siehe: Reproduzierbare Builds, spezieller Client-Support und mehr bei IzzyOnDroid). Was ist seitdem passiert? Wie hat es sich entwickelt? Was haben wir gelernt?

Sicherheitsmaßnahmen

Natürlich haben wir die Scans nicht nur erstellt, und es dann dabei belassen:

• Seit Juli 2024 gibt es im IzzyOnDroid-Repository keine APKs mit Debug-Zertifikaten mehr. Die meisten Apps wurden auf korrekte Release-Keys umgestellt. Andere wurden aus unserem Repo entfernt, da die Entwickler nicht erreicht werden konnten oder das Projekt tot war – in einigen Fällen war sogar das Repo zusammen mit seinem Account bei Codeberg/Github/GitLab verschwunden.
• Wann immer eine App-Aktualisierung die Scanner-Reports mit sensiblen Berechtigungen, Flags oder Intent-Filtern auslöste, haben wir uns mit den Entwicklern in Verbindung gesetzt. Oft wurden Berechtigungen unbeabsichtigt durch eine Abhängigkeit „eingeschleppt” und dann nach unserem Hinweis entfernt, verbleibende Details wurden geklärt. Mittlerweile sollten bei den meisten Apps die richtigen Details für jede APK-Datei im Abschnitt „Packages“ unseres Repo-Browsers aufgeführt sein (siehe Screenshot). Dies hat also nicht nur zu mehr Transparenz geführt, sondern oft auch zu weniger von den Apps angeforderten Berechtigungen.
• Wenn eine App BLOBs in APK-Signaturblöcken enthielt, haben wir die Entwickler darauf hingewiesen und ihnen Tipps gegeben, wie sie diese vermeiden können. Fast jedes Mal (mit einer einzigen Ausnahme bisher) wurde auch dieses Problem beseitigt.
• Mehrere Sicherheitspatches wurden im April auf die fdroidserver-Installation bei IzzyOnDroid angewendet. Natürlich haben wir sie „upstream” zur Verfügung gestellt, nachdem wir sie hier getestet hatten, aber sie waren dort nicht erwünscht (F-Droid.org hat stattdessen eine andere, von ihnen selbst geschriebene Implementierung verwendet, die das meiste davon abdeckt – aber leider u. a. die Unterstützung für Apps, die Signing Key Rotation verwenden, bricht; solche Apps werden bei IzzyOnDroid jedoch weiterhin unterstützt).

Reproducible Builds

Statistiken

Als wir am 1. August 2024 mit unseren RBs live gingen, waren 18% unserer Apps reproduzierbar – eine von sechs. Im Oktober desselben Jahres, nur zweieinhalb Monate später, erreichten wir den Meilenstein von 25%: eine von vier Apps war reproduzierbar. Die 30%-Marke wurde Anfang Dezember erreicht, und die Zahlen steigen weiter.

Wir haben jetzt mehrere Verification Builder, die jeweils von ihren eigenen Betreibern verwaltet werden. Einige werden von unserem Team betrieben, andere von Leuten aus der Community, die uns unterstützen wollen (oder ein Auge darauf haben möchten, was wir wirklich ausliefern und bestätigen? Egal: unabhängige Kontrollen sind wichtig, also seid willkommen, Euch zu beteiligen!). Die Abdeckung ist unterschiedlich: die jeweiligen Betreiber entscheiden selbst, welche Anwendungen sie bauen und überprüfen wollen. Die von unserem Team betriebenen Builder konzentrieren sich natürlich auf die im IzzyOnDroid Repo bereitgestellten Apps, aber die Builder sind nicht darauf beschränkt. Da einige Apps aus unserem Repo auch über das F-Droid.org-Repo verfügbar sind, werden auch diese abgedeckt – vorausgesetzt, sie sind auch dort für Reproducible Builds eingerichtet (unsere Builder verifizieren die APKs, die von ihren jeweiligen Entwicklern erstellt und signiert wurden, während Apps, die nicht für RB bei F-Droid eingerichtet sind, dort mit einem von F-Droid generierten Schlüssel signiert werden und daher nicht identisch sind). Zum jetzigen Zeitpunkt sind drei Builder bei unserem Repository Browser „registriert“. In alphabetischer Reihenfolge ihrer Betreiber:

• Ben betreibt bg443 seit 10/2024. Dies ist ein unabhängiger Builder.
• Fay betreibt obfusk seit 2/2024. Dies ist der originale Builder (Fay hat die Software entwickelt), jedoch derzeit im Wartungs-Modus.
• Izzy betreibt izzy seit 7/2024. Dies ist derzeit der Builder mit der größten Abdeckung.

Beim „izzy builder“ werden derzeit täglich die Updates von etwa 10 Apps geprüft.

Kein Set-and-Forget

Es ist kein einfaches „Richte es ein und es läuft“, und das wussten wir schon vorher. Während ich dies schreibe, warten vier der 370 RB-Apps in meinem Builder darauf, „repariert“ zu werden – eine wurde gerade in Zusammenarbeit mit ihrem Entwickler repariert, also warten noch drei. Und es geht nicht nur uns so, F-Droid.org hat die gleichen Probleme: sucht einfach einmal bei Github nach Issues mit dem Titel „F-Droid can’t build“…

Dinge entwickeln sich weiter. Entwickler arbeiten weiter an ihren Apps, ändern Dinge, fügen Bibliotheken hinzu/ersetzen sie, wechseln vielleicht sogar die Frameworks. Neue Versionen von AGP (dem Android Gradle Plugin), Android-Buildtools und anderen Frameworks, die bei der App-Entwicklung verwendet werden, beheben alte Fehler (so dass Rezepte für neue Versionen von Apps möglicherweise ihre Workarounds entfernen müssen) und führen neue Fehler ein (die wir dann umgehen müssen).

Einige Frameworks und Tools erfordern, dass ihre Versionen zwischen den Builds der Entwickler und den RB-Verifikations-Buildern synchron gehalten werden. Wir haben keine vollständige Liste dafür, aber klassische Beispiele sind Flutter und Rust. Aber auch eine andere Version von cmake kann dazu führen, dass eine App bei RB durchfällt – oder die Aktualisierung einer Abhängigkeit zieht etwas hinein. Natürlich versuchen wir bei der Erstellung des ursprünglichen Rezepts für eine App, alles zu berücksichtigen – gemeinsam mit den Entwicklern. Aber wenn ein neues Tool ins Spiel kommt, kann es sein, dass es ein solches Problem aufwirft – oder einfach eine Aktualisierung unserer Build-Rezepte benötigt. Die Rezepte entwickeln sich also mit neuen Versionen weiter, sie bleiben nicht in einem „eingefrorenen Zustand” oder beheben sich auf magische Weise.

Das gilt auch für Linux-Distributionen. Fedora ist dazu übergegangen, zlib durch zlib-ng zu ersetzen (und es sieht so aus, als ob Arch dasselbe getan hat) – was zu Problemen mit RB führt, da deren Kompression nicht einfach reproduziert werden kann: die mit zlib-ng komprimierten Daten ändern sich, je nachdem, wie die unkomprimierten Daten in den Kompressor eingespeist werden; anders als bei zlib. Das macht die Reproduktion von Daten praktisch unmöglich, es sei denn, man verwendet exakt denselben Code. Was es noch „lustiger” macht, ist, dass abhängig von der Toolchain (statisch gelinkte versus dynamisch gelinkte Binärdateien) einige Dateien in der APK immer noch mit zlib komprimiert werden, während andere mit zlib-ng komprimiert werden... Dieser „Spaß” könnte noch zunehmen, wenn Debian nachzieht und zlib-ng einsetzt, was in ihren Mailinglisten diskutiert und sogar als RB beeinträchtigend angegeben wird: „APKs, die auf einem Debian-System gebaut wurden, werden einen anderen komprimierten Stream haben […], was wahrscheinlich das Reproducible Builds Tooling beeinträchtigen wird“. Und noch schlimmer, „Programme, die früher mit zlib identische und deterministische Ausgaben produzierten, tun dies nicht mehr mit zlib-ng, obwohl sie genau die gleiche zlib-ng .so verwenden”.

Wie bei den Sicherheitsmaßnahmen ist auch die Reproduzierbarkeit von Anwendungen kein Selbstläufer. Sie erfordert ständige Pflege.

Kooperation erforderlich

Bei IzzyOnDroid mögen wir keine „Machtstrukturen“ – wir bevorzugen Zusammenarbeit. Es ist also kein „melde es den Entwicklern und lass sie es beheben“ – es ist ein „versuche es zuerst selbst zu beheben; wenn das nicht klappt, wende dich an die Entwickler und frage, wie wir es gemeinsam beheben können“. Und das betrifft sowohl die Einrichtung von RBs für eine App beim ersten Mal als auch die Reparatur, wenn sie kaputt gehen.

Diese Zusammenarbeit hat sich nicht nur als hilfreich erwiesen, um RBs einzurichten oder zu beheben. Beide Seiten haben dabei eine Menge gelernt. Die Entwickler sahen unser Interesse daran, ihnen zu helfen, ihre Anwendungen als RB zu erproben, und waren begierig, mehr darüber zu erfahren, was es bedeutet und wie es funktioniert. Manchmal erstellten sie die notwendigen Schritte für uns (sogar mit Build-Skripten, die wir über unsere Rezepte aufrufen konnten). Andere wechselten z. B. zu Github-Workflows, um ihre Anwendungen sauber und konsistent zu erstellen, wobei sie unsere Rezepte als Anleitung nutzten. Sie halfen uns, ihr Tooling zu verstehen und unsere Rezepte zu verbessern, während wir ihnen helfen konnten, ihre eigenen Builds zu verbessern. Beide Seiten waren von dem Prozess und den neu gewonnenen Erkenntnissen fasziniert.

Solltest du ein Entwickler sein, deine App bei IzzyOnDroid gelistet haben und reproduzierbare Builds dafür etablieren wollen, kannst du dich gerne an uns wenden – entweder in deinem eigenen Issue Tracker oder in unserem. Wir werden unser Bestes tun, um dir zu helfen.

Ausblick

Dank unserer Unterstützer können wir bald neue Hardware einsetzen: Der Server, auf dem unsere Reproducible Builds laufen, wird ein Hardware-Upgrade erhalten, und ein neuer Mirror wird eingerichtet, der letztendlich unser neues Staging-Setup werden könnte. Wir möchten uns daher ausdrücklich bei allen bedanken, die uns unterstützen, aber insbesondere, in alphabetischer Reihenfolge, bei…

• Aayush Gupta (der Android-Entwickler und FOSS-Enthusiast, den ihr vielleicht als Betreuer von AuroraStore kennt) wurde Sponsor auf unserem OpenCollective und hilft uns damit, regelmäßige Ausgaben wie Hosting/Serverkosten zu decken.
• Andrew Lewman der einen Mirror von IzzyOnDroid betreibt und uns bald einen eigenen Rechner für einen unserer Builder zur Verfügung stellen wird
• BlissLabs, unser Fiscal Host bei OpenCollective. BlissLabs wird uns in Zukunft wohl auch in Sachen Infrastruktur unterstützen.
• Codeberg beherbergt einen Großteil unserer Infrastruktur und betreibt derzeit einen weiteren unserer Mirrors (und ja, wir planen, unsere Zusammenarbeit zu vertiefen)
• Alle anderen, die uns in irgendeiner Weise geholfen haben, sei es durch kleine Spenden, durch das Überprüfen alter Apps und das Melden von Apps, die nicht mehr funktionieren (z. B. weil der Dienst dahinter verschwunden ist oder seine API nicht mehr funktioniert – ihr wisst schon, welche Videoplattform ich da im Sinn habe), durch das Melden von geänderten URLs, durch das Vorschlagen neuer Apps, oder einfach nur durch das Senden eines herzlichen „Kopf-Hoch“/„Danke“ als „Toot“ an @IzzyOnDroid@floss.social…

Ihr seid alle großartig und gebt uns die Motivation, weiterzumachen: Danke dafür!

Eine weitere Sache, an der wir derzeit arbeiten und die in der Vergangenheit mehrfach angefragt wurde, sind Download-Statistiken. Wir werden hoffentlich bald in der Lage sein, tägliche Statistiken mit wöchentlichen Berichten zur Verfügung zu stellen. Die Daten werden im JSON-Format bereitgestellt. Wenn jemand ein Frontend dafür entwickeln möchte (Android-App oder Website-Seite) und vorab eine Datenprobe haben möchte, lasst es uns bitte wissen!

Im September 2024 haben wir unser OpenCollective gegründet. Der „Inflow“ ist noch relativ klein, ebenso wie unser Team. Wir werden IzzyOnDroid in unserer Freizeit weiter betreiben (zum Zeitpunkt dieses Schreibens wird keiner von uns für die Arbeit an dem Projekt bezahlt). Wenn du dazu in der Lage bist, wären Beiträge zu unserem OpenCollective sehr willkommen. Wir hoffen, dass wir genug Geld zusammenbekommen, um mindestens einem Teammitglied zu ermöglichen, an IzzyOnDroid als „Teilzeitjob“ zu arbeiten, anstatt nur in seiner Freizeit.

Letzte Worte (für 2024 in diesem Blog)

Wie bei den Sicherheitsmaßnahmen ist auch die Aufrechterhaltung reproduzierbarer Builds ein kontinuierlicher Prozess, der ständige Aufmerksamkeit und Sorgfalt erfordert. Es ist nicht immer einfach, aber wir glauben, dass sich die Mühe lohnt. Für diejenigen, die unser Repository nutzen, bedeutet dies, dass sie überprüfen können, ob eine Anwendung wirklich aus dem angegebenen Quellcode erstellt wurde, ohne dass etwas hinzugefügt oder weggenommen wurde – was der Fall ist, wenn der „grüne Schild“ aktiviert ist. Da der Prozess nicht immer trivial ist, erscheint der grüne Schild manchmal verzögert (während wir versuchen, ein fehlgeschlagenes Rezept zu reparieren), oder es erscheint stattdessen ein gelber Schild, der ein fehlgeschlagenes RB signalisiert (das für diese Version nicht behoben werden kann). Selbst das bedeutet keine Gefahr; manchmal kann eine APK aufgrund kleinerer Fehler im Erstellungsprozess (eine Datei, die vergessen wurde einzuchecken, ein Build aus einem „dirty tree“ mit lokalen Änderungen oder Artefakten, die von früheren Builds übrig geblieben sind) nicht als RB erstellt werden. In der Regel stehen wir bereits in Kontakt mit den entsprechenden Entwicklern, um die nächste Version wieder zum Fliegen zu bringen.

Für Neugierige: Wir pflegen auch Wiki-Seiten mit Hinweisen für Entwickler (wie z. B. Best Practices, Hinweise worauf zu achten ist um zu vermeiden, dass RB für ihre Anwendung kaputt geht, oder sogar, wie man einen eigenen Verifizierungsserver einrichtet und betreibt), die ihr euch vielleicht einmal ansehen wollt.