2025-08-03 SSP Wallet v1.25.0 dostarczyła dwie zmiany, które razem naprawiają jedną z najstarszych przemilczanych słabości dystrybucji portfeli: nie musisz już ufać, że plik binarny w sklepie to plik binarny z repozytorium. Wydania są teraz budowane deterministycznie w Dockerze i podpisywane GPG. Każdy — nie tylko my, nie tylko audytor — może przebudować ze źródeł i sprawdzić, że to, co otrzymał, zgadza się bajt po bajcie z tym, co opublikowaliśmy.
Nie ufaj, weryfikuj — zastosowane do plików binarnych portfela
Bitcoinowe motto „nie ufaj, weryfikuj" zwykle pada w kontekście transakcji. Z tą samą siłą stosuje się do oprogramowania, które je podpisuje. Kod portfela może być otwarty i poddany audytowi, a mimo to wysłać skompromitowany plik binarny, bo droga od kodu do binarki prowadzi przez serwer build, krok pakowania, klucz code-signing i upload do sklepu. Każde ogniwo może zostać zatrute. Wyciekły token CI, podmieniony plik binarny w pipeline, zmanipulowany agent build — żadne z tego nie dotyka publicznego repozytorium i żadne nie jest widoczne w git log.
Defensywna odpowiedź na ten model zagrożeń: sam plik binarny musi być weryfikowalny. Nie „weryfikowalny, bo obiecujemy". Reprodukowalny przez nieznajomych.
Deterministyczne buildy w Dockerze
To właśnie dostarcza v1.25.0. Każde wydanie SSP jest teraz budowane w kontenerze Dockera z przypiętym obrazem bazowym, przypiętymi wersjami toolchaina i całkowicie izolowanym środowiskiem. Build nie ma dostępu do sieci tam, gdzie nie musi, nie wycieka systemu plików hosta, nie wpisuje znaczników czasu ani ścieżek specyficznych dla maszyny do wyniku. Wyjście jest deterministyczną funkcją wejść.
Praktyczna konsekwencja: identyczny kod źródłowy produkuje identyczne pliki binarne z pasującymi sumami kontrolnymi. Weź tag, zbuduj go w udokumentowanym kontenerze na swojej maszynie, a otrzymasz tę samą SHA-256, co my. Jeśli nie — coś rozjechało się między tagiem a opublikowanym plikiem binarnym, i właśnie tego sygnału chcesz, bo jedynym uczciwym wynikiem jest „binarka zgadza się z kodem" albo „nie zgadza się".
To mitygacja ataków na łańcuch dostaw. Nie zakłada, że serwer build jest uczciwy. Nie zakłada, że laptop developera jest czysty. Nie zakłada niczego i daje nieznajomym narzędzia, by sprawdzić.
Wydania podpisane GPG
Reprodukowalność mówi, że plik binarny odpowiada drzewu źródeł. Sama z siebie nie mówi, które drzewo źródeł jest prawdziwe. To rozwiązuje podpis GPG.
Każdy artefakt v1.25.0 — paczki rozszerzenia, plik z sumami kontrolnymi — jest podpisany kluczem release SSP. Podpis publikowany jest obok wydania na GitHubie. Aby zweryfikować pobranie, importujesz klucz publiczny raz, uruchamiasz gpg --verify na podpisie, a narzędzie mówi, czy plik jest nienaruszony i czy klucz podpisujący to ten, którego się spodziewasz.
Oba mechanizmy się komponują. Podpis GPG dowodzi „to jest plik, który opublikowała SSP". Deterministyczny build dowodzi „ten plik odpowiada temu commitowi". Razem usuwają lukę zaufania między commitem a instalacją.
Jak samemu zweryfikować wydanie
Strona wydania na GitHubie jest miarodajnym źródłem dokładnych kroków — odcisk klucza publicznego, nazwy plików podpisów, polecenie Docker do reprodukcji buildu. Krótka wersja: zaimportuj klucz release SSP, pobierz plik z sumami kontrolnymi i jego podpis, uruchom gpg --verify na podpisie, a potem sha256sum -c z sumami przeciw pobranemu plikowi binarnemu. Jeśli oba przejdą, artefakt jest nienaruszony i autentyczny.
Zaawansowani użytkownicy, którzy chcą iść dalej, mogą sklonować tag, uruchomić udokumentowany build Dockera i potwierdzić, że wynikowa SHA-256 zgadza się z opublikowaną sumą kontrolną. Większość nigdy tego nie zrobi. Rzecz w tym, że niektórzy zrobią, a wystarczy jeden taki, który znajdzie rozbieżność, by ujawnić atak natychmiast.
Co to zmienia
SSP jest open source od v1.0.0 i audytowany przez Halborn od końca do końca od pełnego przeglądu opublikowanego na początku 2025. v1.25.0 zamyka trzeci bok tego trójkąta. Open source znaczy, że możesz przeczytać kod; audytowany znaczy, że eksperci go zbadali; reprodukowalny plus podpisany znaczy, że to, co działa na twojej maszynie, naprawdę jest kodem, który przeczytałeś.
Te trzy gwarancje są niezależne i komponują się. Nieprodukowalna binarka open-source wciąż może ukrywać kompromitację w pipeline build. Nieprodukowalny audytowany projekt wciąż może wysłać zmanipulowaną binarkę, której audytorzy nigdy nie widzieli. Z v1.25.0 „weryfikuj przed instalacją" przestaje być aspiracją i staje się konkretną listą.
To opowieść o łańcuchu dostaw portfela self-custody, opowiedziana jedynym uczciwym sposobem.