Reproduzierbare Builds stellen eine überprüfbare Verbindung zwischen dem veröffentlichten Quellcode und der Binärdatei eines Releases her. Unsere Abdeckung reproduzierbarer Builds erstreckt sich derzeit auf das F-Droid-Release für Android. Wir beabsichtigen, diese Abdeckung auf weitere Android- und iOS-Vertriebskanäle auszuweiten.

Android

F-Droid

Gem Wallet nutzt die unabhängige F-Droid-Build-Infrastruktur, um die F-Droid-APK neu zu bauen und sie vor der Veröffentlichung zu verifizieren.

Verifikationsmodell

Gem Wallet veröffentlicht für jedes Release eine signierte F-Droid-APK. Unabhängig davon führen die F-Droid-Build-Server das öffentliche Build-Rezept in einer sauberen Umgebung aus:

  1. Die F-Droid-Metadaten legen einen exakten Git-Commit und eine exakte Android-NDK-Version fest.
  2. F-Droid checkt diesen Commit aus dem öffentlichen Repository von Gem Wallet aus.
  3. Die öffentlichen Skripte für reproduzierbare Builds installieren die gepinnte native Toolchain und führen :app:assembleFdroidRelease aus.
  4. Der Build erzeugt eine unsignierte APK. F-Droid lädt die zugehörige, vom Entwickler signierte APK herunter und bestätigt, dass sie mit dem in AllowedAPKSigningKeys deklarierten Zertifikats-Fingerabdruck signiert ist.
  5. F-Droid kopiert die APK-Signatur auf das neu gebaute Artefakt und verifiziert sie. Signaturen nach Android APK Signature Scheme v2/v3 decken die gesamte APK außerhalb des Signaturblocks ab, sodass eine erfolgreiche Verifikation voraussetzt, dass die Nutzdaten der neu gebauten APK Byte für Byte mit dem Release von Gem Wallet übereinstimmen.
  6. F-Droid veröffentlicht die vom Entwickler signierte APK nur, wenn die Verifikation erfolgreich ist. Ein Release, das sich nicht reproduzieren lässt, wird nicht veröffentlicht.

Kontrollen für deterministische Builds

Gem Wallet enthält native Rust-Bibliotheken, wodurch das Ergebnis empfindlich auf Unterschiede bei Compiler, Linker, NDK, Host-Plattform und Optimierer reagiert. Der F-Droid-Build kontrolliert diese Eingaben durch folgende Maßnahmen:

  • Pinnen der Versionen der Rust-Toolchain und von cargo-ndk in android/reproducible/versions.sh;
  • Installation von cargo-ndk mit --locked, während die Rust-Abhängigkeiten der Anwendung über die eingecheckte Cargo.lock aufgelöst werden;
  • Pinnen der exakten Android-NDK-Revision sowohl im Android-Projekt als auch in den F-Droid-Metadaten;
  • Bauen auf einem x86_64-Linux-Host mit expliziten Pfaden zu Linker und Archiver des NDK;
  • Beschränkung der nativen APK-Ziele auf armeabi-v7a und arm64-v8a, unabhängig vom x86_64-Build-Host;
  • Verwendung des dedizierten Produktkanals fdroid, ohne die Push- und Review-Module von Google;
  • Deaktivierung der R8-Optimierung mit -dontoptimize, um nichtdeterministische DEX-Ausgaben und Mapping-Bezeichner zu verhindern;
  • Ausführung von Gradle ohne Daemon und Konfigurations-Cache sowie Leeren der Transformations-Caches vor dem Release-Build.

Der exakte Quell-Commit, die Build-Befehle, der Ausgabepfad, die NDK-Revision, die URL der Upstream-APK und das zugelassene Signaturzertifikat sind in den F-Droid-Metadaten öffentlich einsehbar. Die Skripte, die Rust, Cargo, die NDK-Toolchain und Gradle konfigurieren, werden zusammen mit dem Quellcode der Anwendung unter android/reproducible gepflegt.

Sicherheitseigenschaften und Grenzen

Eine erfolgreiche F-Droid-Verifikation zeigt, dass sich die von Gem Wallet veröffentlichte signierte APK aus dem deklarierten Quell-Commit und dem Build-Rezept reproduzieren lässt. Der Nachbau erfolgt außerhalb der Infrastruktur von Gem Wallet und verringert damit die Abhängigkeit von unserer Release-Pipeline als einzigem Vertrauenspunkt.

Reproduzierbarkeit beweist nicht, dass der Quellcode frei von Schwachstellen ist, dass jede Abhängigkeit vertrauenswürdig ist oder dass die gewählte Compiler-Toolchain frei von Kompromittierungen ist. Diese Risiken erfordern zusätzlich zu reproduzierbaren Builds eine Prüfung des Quellcodes, Kontrollen der Abhängigkeiten und die Absicherung der Toolchain.

Der Build-Status und die verifizierten Releases sind auf der F-Droid-Seite von Gem Wallet verfügbar.

Universal APK und Google Play

Die universelle APK von Gem Wallet und das Google-Play-Release sind derzeit nicht durch die oben beschriebene F-Droid-Verifikation abgedeckt. Die Unterstützung reproduzierbarer Builds für diese Android-Vertriebskanäle ist für die Zukunft geplant.

iOS

Das App-Store-Release ist derzeit nicht reproduzierbar. Die Unterstützung reproduzierbarer Builds für iOS sowie die unabhängige Verifikation der App-Store-Binärdatei sind für die Zukunft geplant.

Frequently Asked Questions

Reproduzierbare Builds ermöglichen es jedem, Gem Wallet aus dem öffentlichen Quellcode zu bauen und zu verifizieren, dass die resultierende App mit dem offiziellen Release übereinstimmt. Das schafft zusätzliche Transparenz und hilft zu bestätigen, dass die veröffentlichte App aus demselben Quellcode gebaut wurde, der auf GitHub verfügbar ist.
Open Source bedeutet, dass der Quellcode von Gem Wallet öffentlich verfügbar ist und von jedem überprüft werden kann. Reproduzierbare Builds gehen einen Schritt weiter: Unabhängige Entwickler und Dienste wie F-Droid können die App aus dem deklarierten Quellcode bauen und verifizieren, dass die resultierende Android-APK Byte für Byte mit dem offiziellen Release von Gem Wallet übereinstimmt.
Ja. Sie können sowohl die Android- als auch die iOS-App aus dem öffentlichen Quellcode von Gem Wallet bauen. Die Android-App unterstützt reproduzierbare Builds mithilfe der öffentlichen Build-Skripte und der gepinnten Toolchain. Sie können die iOS-App auch lokal bauen und ausführen.
Die Skripte für reproduzierbare Builds und die gepinnte Toolchain-Konfiguration sind öffentlich. Die F-Droid-Metadaten deklarieren für jedes Release den exakten Quell-Commit, die Android-NDK-Revision, die Build-Befehle und die erwartete APK-Ausgabe. F-Droid baut die Android-App unabhängig neu und veröffentlicht sie nur, wenn die Nutzdaten der APK Byte für Byte mit dem Release von Gem Wallet übereinstimmen.
Wenn Sie eine Frage haben, auf ein Build-Problem stoßen oder eine Abweichung feststellen, erstellen Sie bitte ein Issue im GitHub-Repository von Gem Wallet. Fügen Sie Informationen zu Ihrer Umgebung, Ihren Build-Schritten und allen relevanten Fehlermeldungen bei, damit wir das Problem untersuchen können.