IzzyOnDroid

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

Privacy Links

↓ Your product here? ↓

Das Inoffizielle Android-Handbuch Android kennenlernen, Tipps & Tricks Für EUR 16,99 bei Amazon kaufen

Das Inoffizielle Android Systemhandbuch Tiefer ins System einsteigen Für EUR 7,00 bei Amazon kaufen

Die besten Android-Apps Den Androiden austatten Für EUR 5,00 bei Amazon kaufen

 

Reproducible Builds, besondere Client-Unterstützung und mehr in unserem Repo

Conceptual image - success of teamwork
© Vic (CC-BY); Quelle: Flickr

Heute haben wir einie spannende Neuigkeiten für Euch. Lasst mich gleich mit dem „größten Fisch“ anfangen:

Seit einigen Monaten bietet das IzzyOnDroid-Repository Unterstützung für Reproducible Builds – aber wir haben uns entschieden, dies nicht öffentlich bekannt zu machen, bevor wir aus der „POC-Phase“ heraus sind:

Reproducible Builds

Warte mal: RBs bei IzzyOnDroid? Ist das nicht ein „binäres Repository“, das lediglich die von den jeweiligen Entwicklern erstellten und signierten APKs bereitstellt? Ja, das ist völlig korrekt – und das wird auch so bleiben. Aber ist das nicht ein Widerspruch? Wie Ihr gleich sehen werdet, keinesfalls. Mit Hilfe der Android Reproducible Builds-Expertin Fay (auch bekannt als obfusk), die in der Vergangenheit in ihrer Freizeit auch dabei geholfen hat, diese auf F-Droid.org zu etablieren, das sich bis heute auf ihre Tools¹ stützt, haben wir einen anderen Ansatz gefunden. Und der hat sich als ziemlich gut erwiesen.

Wie funktionieren also reproduzierbare Builds mit einem Repository, das lediglich die APK-Dateien von den jeweiligen Entwicklern übernimmt? Durch die Verwendung von unabhängigen "Verification Builders". Zu diesem Zweck hat Fay rbtlog erstellt, das die APK-Dateien aus den Repositories der Apps zieht, den Code aus demselben Tag auscheckt, die APK-Dateien aus dem Quellcode baut – und dann prüft, ob die resultierenden APKs mit denen identisch sind, die von den Entwicklern ausgeliefert wurden. Wenn dies der Fall ist, findet Ihr einen entsprechenden Hinweis für diese Version in der „Packages“ Sektion der App, wo er etwa folgendermaßen aussehen wird:

Doppelt verifiziert: Gleich zwei Builder haben die Reproduzierbarkeit dieser APK-Datei bestätigt
(Screenshot zum Vergrößern anklicken)

Wer die Maus über einen solchen „Shield“ bewegt erfährt Einzelheiten darüber, welcher Builder dies bestätigt hat – und ein Klick auf den Shield führt zu den Details („Proof” bzw. Beweis). Derzeit sind zwei Builder in Betrieb² (ein dritter wird gerade eingerichtet, während ich dies schreibe). Einer wird von Fay selbst betrieben, der andere von Izzy:

Ich habe IzzyOnDroid 2013 gegründet; ursprünglich lediglich mit den App-Listen. Im Juli 2014 kam dann dieses Blog dazu – und 2016 schließlich das F-Droid kompatible App-Repository, über das wir hier reden. Ein sehr großer Teil meiner freien Zeit fließt in das IzzyOnDroid Projekt. Es macht mir Spaß, Menschen auf diese Weise zu helfen, ihre Privatsphäre und Sicherheit auf ihren Android-Geräten zu verbessern – seien es diejenigen, die die Apps verwenden, oder die die sie erstellen. Ich bin auch IzzyOnDroid’s „Outreach Person“ – und derjenige, der diesen Artikel schreibt (ausgenommen natürlich die persönlichen Zitate).

Übrigens kann jeder einen solchen Builder betreiben – schließlich ist er quelloffen und unter einer freien (libre) Lizenz erhältlich. Es ist auch alles gut dokumentiert (die einzigen Probleme, die ich hatte, um es zum Laufen zu bringen, waren eher Python-bezogen: Ich wollte die Abhängikeiten im System möglichst über Debian-Pakete gelöst wissen – und nur was es dort nicht gibt, mittels pip in ein venv installieren. Sobald das gelöst war, lief alles andere wie geschmiert!). Natürlich helfen wir anderen gern, wenn Hilfe dabei benötigt wird.

Fay vom rbtlog Projekt hat mir sehr dabei geholfen, Catima reproduzierbar zu machen und mir die Gewissheit zu geben, dass Izzy genau das ausliefert, was ich an die Benutzer zu senden beabsichtige. Ich bin sehr froh zu sehen, wie viele Gedanken in diese Implementierung gesteckt wurden und wie genau die Umgebung protokolliert wird, in der der Build stattfand.

Ich schrieb „die Maus über einen solchen Shield bewegen“ – und dabei ist mir klar, dass es so etwas auf einem Touchscreen nicht gibt (na ja, manchmal klappt es mit „lange drücken“ und dann auf „zurück“ gehen). Aber keine Sorge, bald seid Ihr auch auf Euren mobilen Geräten versorgt – wie weiter unten beim Client-Support beschrieben.

Kurz zusammengefasst für diejenigen unter Euch, die sich jetzt fragen: „Wozu soll das gut sein? Und was bedeutet es, wenn eine App Reproducible Builds hat?" Nun: Es sagt Euch, dass die APK tatsächlich aus genau den Quellen (bei Codeberg, Github, GitLab usw.) erstellt wurde, aus denen der Entwickler sie erstellt zu haben behauptet. Dass da kein Code war, der nicht in das Quell-Repo übertragen wurde – und auch nichts im Nachhinein in die APK-Datei „injiziert“ wurde. Dies ist also ein weiteres Sicherheitsmerkmal. Andererseits: Sollte ein Build nicht reproduzierbar sein, bedeutet das nicht unbedingt, dass er manipuliert wurde. Oft sind es ganz einfache Dinge, wie z.B., dass der Entwickler es nicht aus dem Commit des Tags gebaut hat, sondern irgendwo zwischen den Commits – was dann natürlich schwer oder gar nicht reproduzierbar ist. Wenn Du der Entwickler einer App bist, die bei IzzyOnDroid gelistet ist (oder gelistet werden soll), und Du dabei auf RBs hoffst: Wir haben da eine Wiki-Seite mit Tipps vorbereitet, die dabei helfen sollen.

IzzyOnDroid Monitoring mit Uptime Kuma

Hinweis und Disclaimer: Zum Zeitpunkt der Erstellung dieses Artikels haben etwa 18% der Apps (mehr als jede sechste App), die im IzzyOnDroid-Repository verfügbar sind, bereits reproduzierbare Builds. Wir arbeiten hart daran, diese Zahl zu erhöhen. Dies wird jedoch niemals alle Apps abdecken: einige können einfach keine reproduzierbaren Builds erreichen, andere können wir nicht einmal selbst bauen. Wir können auch nicht garantieren, dass wir mit zukünftigen Änderungen an den Android-Tools „Schritt halten“ (in der Vergangenheit waren auf unserer Seite mehrere Anpassungen für Änderungen erforderlich, die Google z. B. an AGP (dem Android Gradle Plugin) vorgenommen hat). Wir können also nicht garantieren, dass dies "für immer reibungslos läuft" (obwohl wir natürlich unser Bestes geben) – aber es wird auch nicht zu Verzögerungen bei den Veröffentlichungen von Apps kommen oder gar zu „kaputten Builds“, sollte etwas mit RB schief laufen.

Monitoring

Dies ist schon länger kein Geheimnis mehr: Die Verfügbarkeit der Services für das IzzyOnDroid Repository wird überwacht, und ihr Status lässt sich jederzeit einsehen. Ermöglicht hat dies unsere großartige SysAdmin, Sylvia:

Meiner Meinung nach ist eine gute Überwachung entscheidend für die Zuverlässigkeit eines Projekts. Computer sind von Natur aus komplex, und selbst das am besten konzipierte System kann manchmal versagen. Eine gute Überwachung ermöglicht es, Probleme schnell zu erkennen und zu beheben. Langfristig kann die Überwachung dazu beitragen, Muster aufzuzeigen, die dabei helfen, Fehler zu finden und die Systeme zu verbessern, um die gesamte Zuverlässigkeit noch weiter zu erhöhen.

Sylvia hat Uptime Kuma für IzzyOnDroid mithilfe von Ansible eingerichtet (um sicherzustellen, dass die Konfiguration automatisch und konsistent angewendet wird (um Fehler auszuschließen und sie bei Bedarf schnell wiederherstellen zu können), und sie bezahlt den Server aus eigener Tasche (nein, wir haben derzeit keine „große Finanzierung“). Das hat uns bereits geholfen, Ausfälle frühzeitig zu erkennen und zu beheben, bevor ihr sie bemerkt habt (zumindest hoffen wir das). Vielleicht sollte ich in diesem Zusammenhang auch die Redundanz erwähnen?

Mirrors

Warehouse concept; © mind2byte
CC BY-NC-SA

Ebenfalls kein Geheimnis und bereits seit einer geraumen Zeit öffentlich bekannt sind unsere Mirrors. Einer wird von Codeberg in Deutschland betrieben, der andere von unserem Unterstützer Andrew in den USA:

Reproducible Builds sind für die Sicherheit von Open-Source-Software von entscheidender Bedeutung, da sie es jedem ermöglichen, genau denselben Binärcode aus dem Quellcode nachzubauen. Somit wird sichergestellt, dass es keine versteckten Schwachstellen oder Hintertüren gibt, die während des Build-Prozesses eingeführt werden. Dies ist wichtig für Open-Source-Projekte, da es das Vertrauen und die Transparenz erhöht, indem die Benutzer überprüfen können, ob die Software, die sie verwenden, aus demselben Quellcode erstellt wurde, der öffentlich zugänglich ist. Reproducible Builds helfen auch dabei, Bugs und Fehler frühzeitig im Entwicklungszyklus zu erkennen, da Abweichungen zwischen der erwarteten und der tatsächlichen Ausgabe leicht identifiziert und zum Quellcode zurückverfolgt werden können. Ich freue mich, einen Mirror und einen Builder für dieses Projekt zur Verfügung stellen zu können.

Die URLs dieser Mirrors werden in dem Index aufgeführt, der an die Android-Clients ausgeliefert wird – was bedeutet, dass euer F-Droid Client euch anbieten kann, die Daten (und Apps) von einem anderen Server zu beziehen, falls ein Server (Haupt-Repository oder Mirror) unerreichbar wird. Einige Clients tun dies automatisch (z. B. der offizielle F-Droid-Client), andere lassen Sie manuell umschalten (und einige haben leider keine Mirror-Unterstützung). Mehr dazu im Abschnitt über Client-Unterstützung weiter unten.

Client-Unterstützung

Wir sind begeistert, dies ankündigen zu können, und schätzen das Engagement der Beteiligten sehr! Das IzzyOnDroid-Team hat begonnen, mit LooKeR von Droid-ify zusammenzuarbeiten. Seine Worte zum Thema hier:

Die Verbesserung der Sicherheits- und Datenschutzstandards in FOSS-Android-Anwendungen ist sehr wichtig. Dies ist ein entscheidender Bereich, der sich direkt auf die Nutzererfahrung und das Vertrauen auswirkt. Es ist ziemlich offensichtlich, dass die Menschen einen besseren Datenschutz, mehr Sicherheit und mehr Freiheit in Bezug auf ihre Nutzung verdienen.

Einige aus unserem Team lieben seinen Client und verwenden ihn schon seit langem als Standard. Andere bevorzugen Neo Store von Toni und seinem Team. Und was soll ich sagen? Wir sind stolz darauf, auch Toni an Bord zu haben! Und er blickt noch weiter nach vorne:

Dies sind nur die ersten Schritte bei der Erweiterung der Definition und der Demonstration des Engagements für Sicherheit und Datenschutz in Open-Source-Android-Anwendungen. Es werden weitere Erweiterungen und Modelle folgen, die zu umfassenderen Berichten zu Datenschutz und Sicherheit in den Clients führen werden.

Neo Store (links) und Droid-ify (rechts): zwei exzellente F-Droid Clients
(Screenshots zum Vergrößern anklicken)

Was bedeutet das aber nun für euch, die ihr das IzzyOnDroid Repo und einen dieser zwei feinen Android-Clients verwendet? Ihr werdet viele der oben genannten Details und weitere erhalten, die transparent in eurem Client verfügbar sind. Wir arbeiten derzeit gemeinsam daran: das IzzyOnDroid-Team, um die benötigten Daten bereitzustellen, und die Client-Teams, um sie für euch verfügbar zu machen. Wenn ihr euch demnächst die Details einer App in eurem Lieblings-Client anseht (zumindest wenn es sich um einen dieser beiden handelt), werdet ihr nicht nur die Beschreibung, Screenshots und Links sehen, sondern auch...

• ob die Veröffentlichung der Anwendung als reproduzierbarer Build bestätigt wurde und von welchem/welchen Builder(n)
• welche Bibliotheken in der APK gefunden wurden (Ergebnisse der IzzyOnDroid-Scanner, wie ihr sie bereits im Repo-Browser sehen könnt)
• was andere Scanner zu sagen haben (z. B. VirusTotal)

Geschafft! Ein weiterer Task abgeschlossen

Und das soll erst der Anfang sein. A Ferret’s Work Is Never Done habe ich vor nicht all zu langer Zeit im Fediverse gepostet – und so hoffen wir, dass wir euch in Zukunft weitere spannende Neuigkeiten liefern können. Wie immer, wenn sie verfügbar sind (die Neuigkeiten; aber natürlich auch die Zukunft). Wir wollen keine Versprechungen machen, wenn wir nicht sicher sind, dass wir sie halten können – was wir nicht wissen, bevor wir sie „verPOCed“ haben.

Community

All dies ist die gemeinsame Anstrengung mehrerer Projekte, die sich zusammengetan haben, um für die Community etwas zu erreichen. Es geht nicht nur um IzzyOnDroid, obwohl das IzzyOnDroid-Repository hier eindeutig im Mittelpunkt stand. Hier jedoch haben wir unsere Kräfte gebündelt: das IzzyOnDroid-Team, die beiden Client-Projekte, Fay mit ihrer Sammlung von Tools für reproduzierbare Builds: wir haben uns zusammengesetzt, um herauszufinden, wie wir die Sicherheit und Transparenz für euch verbessern können. Wir alle hoffen, dass uns das gelungen ist – und noch mehr gelingen wird, denn die Arbeit ist nie getan. Und wir werden weiter zusammenarbeiten.

Es war kein „finanzieller Anreiz“ im Spiel. Anders als manch andere Projekte hat IzzyOnDroid keine „große Finanzierung“ in der Hinterhand. Es ist mit Sicherheit kein „venture capitalist“ (Risikokapitalgeber) beteiligt (und wird es auch nie sein). Aber es gibt auch keine Grants oder andere Zuschüsse. Wenn also Ausgaben anfallen, decken wir sie aus eigener Tasche: Sylvia für den Monitoring-Server, Izzy für die anderen IzzyOnDroid-Server. Dankenswerterweise helfen uns hier einige Mitglieder der Community.

Wer an dieser Stelle mithelfen möchte: Wir könnten etwas „Serverplatz“ für (weitere) Verifikationsentwickler gebrauchen. Auch um Test-/Staging-Instanzen zu betreiben, auf denen neue Ideen getestet werden können. Mirrors, insbesondere in noch nicht abgedeckten Regionen, wären ebenfalls willkommen. Natürlich nicht nur das: Habt ihr andere Ideen, wie ihr euch ggf. einbringen könntet, meldet euch bitte bei uns! Auch andere Beiträge sind willkommen. Lasst uns wissen, was ihr gut könnt – und wir schauen, wo es reinpasst

Aber es ist uns auch wichtig, euch Danke zu sagen: Danke, dass ihr uns vertraut habt, danke, dass ihr bei uns geblieben seid – und danke, dass ihr diesen Artikel bis zu dieser letzten Zeile gelesen habt