Reproducible Firmware Build to kompilacja, w której ten sam kod źródłowy, środowisko i instrukcje tworzą z góry określone wyniki identyczne bajt po bajcie. Trzeba podać wersję, model urządzenia i zakres porównania, zwłaszcza gdy wydanie zawiera dodatkowy podpis.
Deklaracja dotyczy określonego wyniku, na przykład obrazu firmware, a nie automatycznie każdego pliku lub logu. Równoważne działanie programu nie wystarcza: weryfikacja szuka identycznych bajtów, zwykle za pomocą skrótu kryptograficznego. Otwarty kod bez powtarzalnej kompilacji sam nie wykazuje tego związku z wydanym plikiem binarnym. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Zapisz dokładny commit, zależności i ich wersje, kompilator, opcje kompilacji, istotne zmienne środowiska i model docelowy. Nazwa projektu ani zmienna gałąź nie wystarczą. Informacje potrzebne do powtórzenia powinny być opublikowane lub zapisane podczas kompilacji; inaczej nie da się wiarygodnie ocenić różnic. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
Kompilator może umieścić ścieżkę katalogu roboczego w danych debugowania. Ten sam kod w dwóch lokalizacjach może więc tworzyć różne pliki. Ścieżkę można określić wcześniej lub znormalizować obsługiwaną metodą. Reguła musi należeć do przepisu; późniejsze usuwanie nieznanych różnic podważa weryfikację. [Reproducible Builds — Build paths]
Prawidłowy podpis wiąże wydanie z odpowiednim kluczem podpisującym w danym modelu zaufania. Niezależna kompilacja bada związek między kodem a wynikiem binarnym. Oficjalny podpisany plik może zawierać dane nieobecne w lokalnej kompilacji bez podpisu. Zwykłe porównanie całych plików może więc nie być właściwym testem deklarowanej odtwarzalności. [Trezor — Reproducible build verification]
Dokumentacja Trezor wybiera wersję i model, buduje obraz w określonym środowisku i porównuje go z oficjalnym wydaniem. Przed porównaniem opisuje wyzerowanie ściśle wskazanych pól podpisu; starsze formaty różnią się również nagłówkami. Układ zależy od modelu i wersji. Procedury dla jednego obrazu nie wolno bezrefleksyjnie stosować do innego, a oryginalny podpis weryfikuje się osobno. [Trezor — Reproducible build verification]
Najpierw sprawdź rewizję, model, wariant firmware, zależności i zadeklarowane przekształcenia obrazu. Zachowaj oryginalne pliki i zapis różnic. Niezgodność może wynikać z błędu przepisu lub środowiska, ale też ze zmiany rozpowszechnianego pliku binarnego; sama nie ustala przyczyny. Nie oznaczaj wyniku jako zweryfikowanego, zanim różnica nie zostanie wyjaśniona, a test powtórzony. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Błędny lub złośliwy kod może być w pełni odtwarzalny. Wspólny niezaufany kompilator może wprowadzić tę samą zmianę do wszystkich wyników; ponowne użycie tego samego narzędzia nie jest niezależnym audytem kompilatora. Zamknięte składniki binarne ograniczają to, co można przebudować z dostępnego kodu. Zgodne pliki nie potwierdzają też autentyczności sprzętu ani tego, co faktycznie zainstalowano na konkretnym urządzeniu. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
Przydatny zapis wskazuje, kto kompilował, z którego commitu, według jakiego przepisu, dla którego modelu i jakie pliki porównał. Dodaj algorytm skrótu, wyniki i dokładne wyjątki dotyczące danych podpisu. Dodatkowe niezależne osoby budujące zmniejszają zależność od jednego wydawcy, lecz nie zastępują oceny kodu, procesu aktualizacji i bezpieczeństwa całego urządzenia. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
Ten sam kod, inny obszar podpisu
Dwie osoby używają tego samego commitu, modelu i środowiska. Ich lokalne obrazy mają ten sam SHA-256, a oficjalny podpisany obraz ma inny. Jeżeli dokumentacja precyzyjnie wyznacza pola podpisu, porównują kopie po przepisanym przekształceniu. Zgodność dotyczy wtedy tak określonej treści; oryginalny podpis sprawdza się oddzielnie. Innych różnic nie wolno po prostu usuwać.
Pełniejszy obraz uzyskasz, czytając to hasło razem z Hardware Wallet, Klucz prywatny, Cold Storage, Secure Element. Do tego hasła prowadzą również odsyłacze z COLDCARD RNG Incident (2026).
01Czy zgodny skrót wystarcza, by uznać firmware za bezpieczny?+
Nie. Zgodność wykazuje wynik konkretnego porównania, a nie brak błędów. Złośliwy kod lub wspólny niezaufany kompilator mogą dawać identyczne wyniki. Trzeba oddzielić weryfikację kompilacji, audyt kodu i zaufanie do urządzenia.
02Czy inny skrót podpisanego wydania automatycznie oznacza atak?+
Nie. Podpisany obraz może mieć inne, wcześniej opisane pola podpisu lub nagłówki. Najpierw sprawdź właściwą wersję, model i procedurę porównania. Niewyjaśnionej niezgodności nie wolno jednak uznać za pomyślną weryfikację ani obchodzić dowolnym usuwaniem bajtów.