Reproducible Firmware Build je sestavení, při němž stejný zdrojový kód, prostředí a návod vedou k bajtově shodným předem určeným výstupům. Je nutné uvést verzi, model zařízení a rozsah porovnání, zvlášť pokud vydání obsahuje dodatečný podpis.
Tvrzení se vztahuje na určený výstup, například obraz firmwaru, nikoli automaticky na každý soubor nebo log. Stejná funkce programu nestačí: kontrola hledá stejné bajty, běžně prostřednictvím kryptografického hashe. Otevřený zdrojový kód bez opakovatelného sestavení tuto vazbu s vydanou binárkou sám nedoloží. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Zaznamenejte přesný commit, závislosti a jejich verze, kompilátor, přepínače sestavení, relevantní proměnné prostředí a cílový model. Nestačí pouze název projektu nebo pohyblivá větev. Informace potřebné k opakování mají být zveřejněné nebo zachycené při sestavení; jinak nelze rozdíl spolehlivě vyhodnotit. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
Kompilátor může do ladicích informací zapsat cestu k pracovnímu adresáři. Dvě umístění stejného zdroje pak mohou dát různé soubory. Cestu lze předem určit nebo normalizovat podporovaným postupem. Takové pravidlo musí patřit k receptu; dodatečné mazání neznámých rozdílů by kontrolu znehodnotilo. [Reproducible Builds — Build paths]
Platný podpis váže vydání na příslušný podpisový klíč v daném modelu důvěry. Nezávislé sestavení zkoumá vztah mezi zdrojem a binárním výstupem. Podepsaný oficiální soubor může obsahovat data, která místní nepodepsané sestavení nemá. Prosté porovnání celých souborů pak nemusí být správným testem deklarované reprodukovatelnosti. [Trezor — Reproducible build verification]
Dokumentace Trezor vybírá verzi a model, sestaví obraz v určeném prostředí a porovná jej s oficiálním vydáním. Před porovnáním popisuje vynulování přesných podpisových polí; u starších formátů se liší také hlavičky. Rozložení závisí na modelu a verzi. Postup pro jeden obraz proto nelze slepě použít na jiný a kontrolu původního podpisu je nutné oddělit. [Trezor — Reproducible build verification]
Nejprve ověřte shodu revize, modelu, varianty firmwaru, závislostí a deklarovaných úprav obrazu. Uchovejte původní soubory i záznam rozdílu. Neshoda může být chyba receptu nebo prostředí, ale také změna distribuované binárky; sama neurčuje příčinu. Neoznačujte výstup za ověřený, dokud není rozdíl vysvětlen a kontrola zopakována. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Chybný nebo škodlivý zdroj může být dokonale reprodukovatelný. Společný nedůvěryhodný kompilátor může vložit stejnou změnu do všech výsledků; opakování téhož nástroje není nezávislý audit kompilátoru. Přítomnost uzavřených binárních částí omezuje, co lze z dostupného zdroje přestavět. Shoda souborů rovněž neověřuje pravost hardwaru ani to, co je v konkrétním zařízení skutečně nahráno. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
Užitečný záznam uvádí kdo sestavoval, z jakého commitu, podle jakého receptu, pro který model a které soubory porovnal. Připojte algoritmus hashe, výsledky a přesné výjimky pro podpisová data. Další nezávislí sestavovatelé snižují závislost na jediném vydavateli, ale nenahrazují kontrolu zdroje, aktualizačního procesu a bezpečnosti zařízení jako celku. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
Stejný kód, rozdílná podpisová oblast
Dva sestavovatelé použijí stejný commit, model a prostředí. Jejich místní obrazy mají stejný SHA-256, oficiální podepsaný obraz jiný. Jestliže dokumentace přesně vymezuje podpisová pole, porovnají kopie po této předepsané úpravě. Shoda pak platí pro takto určený obsah; původní podpis se ověřuje samostatně. Jiný rozdíl nesmějí prostě odstranit.
Pro nejúplnější obraz čtěte toto heslo společně s Hardware Wallet, Privátní klíč, Cold Storage, Secure Element. Opačným směrem na něj odkazují také COLDCARD RNG Incident (2026).
01Stačí shoda hashe k závěru, že firmware je bezpečný?+
Ne. Shoda dokládá výsledek konkrétního porovnání, nikoli nepřítomnost chyb. Škodlivý zdroj nebo společný nedůvěryhodný kompilátor mohou vytvářet shodné výstupy. Je nutné oddělit kontrolu sestavení, kontrolu zdroje a důvěru v zařízení.
02Znamená jiný hash podepsaného vydání automaticky útok?+
Ne. Podepsaný obraz může mít jiná předem popsaná podpisová pole nebo hlavičky. Nejprve ověřte správnou verzi, model a porovnávací postup. Nevysvětlenou neshodu však nelze prohlásit za úspěšné ověření ani obejít libovolným mazáním bajtů.