Am 2025-08-03 hat SSP Wallet v1.25.0 zwei Änderungen ausgeliefert, die zusammen eine der ältesten unausgesprochenen Schwächen der Wallet-Distribution beheben: Du musst nicht mehr darauf vertrauen, dass die Binärdatei im Store die Binärdatei im Repository ist. Releases werden jetzt deterministisch in Docker gebaut und mit GPG signiert. Jeder — nicht nur wir, nicht nur ein Auditor — kann aus dem Quellcode neu bauen und prüfen, dass das, was er erhält, Byte für Byte mit dem übereinstimmt, was wir veröffentlicht haben.
Vertraue nicht, verifiziere — angewendet auf Wallet-Binärdateien
Das Bitcoin-Motto „Vertraue nicht, verifiziere" wird gewöhnlich auf Transaktionen bezogen. Es gilt mit gleicher Kraft für die Software, die sie signiert. Der Code einer Wallet kann offen und auditiert sein und trotzdem eine kompromittierte Binärdatei ausliefern, weil der Weg vom Code zur Binärdatei über einen Build-Server, einen Packaging-Schritt, einen Code-Signing-Schlüssel und einen Store-Upload führt. Jedes Glied kann vergiftet werden. Ein geleakter CI-Token, eine ausgetauschte Binärdatei in der Pipeline, ein manipulierter Build-Agent — nichts davon berührt das öffentliche Repository und nichts ist in einem git log sichtbar.
Die defensive Antwort auf dieses Bedrohungsmodell ist, dass die Binärdatei selbst überprüfbar sein muss. Nicht „überprüfbar, weil wir es versprechen". Reproduzierbar durch Fremde.
Deterministische Docker-Builds
Genau das liefert v1.25.0. Jedes SSP-Release wird jetzt in einem Docker-Container mit fixiertem Base-Image, fixierten Toolchain-Versionen und einer vollständig isolierten Umgebung gebaut. Der Build hat keinen Netzwerkzugang, wo er ihn nicht braucht, lässt das Host-Dateisystem nicht durchsickern, bäckt weder Zeitstempel noch maschinenspezifische Pfade in die Ausgabe ein. Die Ausgabe ist eine deterministische Funktion der Eingaben.
Die praktische Folge: identischer Quellcode erzeugt identische Binärdateien mit übereinstimmenden Prüfsummen. Nimm den Tag, baue ihn im dokumentierten Container auf deiner Maschine, und du bekommst dieselbe SHA-256 wie wir. Wenn nicht, ist zwischen Tag und veröffentlichter Binärdatei etwas abgewichen — und das ist genau das Signal, das man will, denn das einzige ehrliche Ergebnis ist „die Binärdatei passt zum Code" oder „sie passt nicht".
Das ist die Supply-Chain-Mitigation. Sie nimmt nicht an, dass der Build-Server ehrlich ist. Sie nimmt nicht an, dass das Notebook des Entwicklers sauber ist. Sie nimmt nichts an und gibt Fremden die Werkzeuge, es zu prüfen.
GPG-signierte Releases
Reproduzierbarkeit sagt dir, dass eine Binärdatei einem Quell-Tree entspricht. Sie sagt dir nicht allein, welcher Quell-Tree der echte ist. Das löst die GPG-Signatur.
Jedes Artefakt von v1.25.0 — die Erweiterungs-Bundles, die Checksum-Datei — ist mit dem SSP-Release-Schlüssel signiert. Die Signatur wird neben dem Release auf GitHub veröffentlicht. Um einen Download zu verifizieren, importierst du den öffentlichen Schlüssel einmal, führst gpg --verify gegen die Signatur aus, und das Tool sagt dir, ob die Datei intakt ist und ob der Schlüssel, der signiert hat, der erwartete ist.
Die beiden Mechanismen komponieren. Die GPG-Signatur beweist „das ist die Datei, die SSP veröffentlicht hat". Der deterministische Build beweist „diese Datei entspricht diesem Commit". Zusammen schließen sie die Vertrauenslücke zwischen Commit und Installation.
Wie du ein Release selbst verifizierst
Die Release-Seite auf GitHub ist die maßgebliche Quelle für die genauen Schritte — Fingerprint des öffentlichen Schlüssels, Dateinamen der Signaturen, Docker-Befehl zur Reproduktion eines Builds. Kurzfassung: Importiere den SSP-Release-Schlüssel, lade die Checksum-Datei und ihre Signatur, führe gpg --verify auf der Signatur aus, dann sha256sum -c mit den Checksums gegen die heruntergeladene Binärdatei. Wenn beides besteht, ist das Artefakt intakt und authentisch.
Power-User, die weiter gehen wollen, können den Tag klonen, den dokumentierten Docker-Build ausführen und bestätigen, dass die resultierende SHA-256 mit der veröffentlichten Prüfsumme übereinstimmt. Die meisten werden das nie tun. Der Punkt ist, dass einige es tun, und dass jeder von ihnen, der eine Abweichung findet, sofort einen Angriff aufdeckt.
Was sich dadurch ändert
SSP ist seit v1.0.0 Open Source und seit der vollständigen Überprüfung Anfang 2025 von Halborn auditiert — Ende zu Ende. v1.25.0 schließt die dritte Seite dieses Dreiecks. Open Source heißt, du kannst den Code lesen; auditiert heißt, Experten haben ihn geprüft; reproduzierbar plus signiert heißt, dass das, was auf deiner Maschine läuft, tatsächlich der Code ist, den du gelesen hast.
Die drei Garantien sind unabhängig und komponieren. Eine nicht reproduzierbare Open-Source-Binärdatei kann immer noch eine Kompromittierung in der Build-Pipeline verbergen. Ein nicht reproduzierbares auditiertes Projekt kann immer noch eine manipulierte Binärdatei ausliefern, die die Auditoren nie gesehen haben. Mit v1.25.0 hört „vor dem Installieren verifizieren" auf, Anspruch zu sein, und wird zur konkreten Checkliste.
Das ist die Supply-Chain-Geschichte einer Self-Custody-Wallet, erzählt auf die einzige Weise, die ehrlich ist.