Reprodukovatelné buildy VPN aplikací: co shoda dokazuje

Reprodukovatelnost je vlastnost dodavatelského řetězce: stejné deklarované vstupy musí vytvořit stejný artefakt. U VPN klienta toto tvrzení svazuje stažený instalátor se zdrojovým kódem a nástroji, které může kdokoli znovu sestavit. O službě, ke které se klient připojuje, neříká nic.

Užitečná otázka je proto úzká a má odpověď. Zveřejňuje projekt postup a odpovídá mu právě váš artefakt?

Kde build přestává být deterministický

Kompilátory vkládají časová razítka, absolutní cesty a názvy hostitelů sestavení, pokud jim to výslovně nezakážete. Archivy zaznamenávají pořadí souborů a časy změn, linkery mění výstup podle verze sady nástrojů a paralelní komprese může přeskupit bloky. Cokoli z toho způsobí, že se dva buildy stejného zdrojového kódu liší v bajtech, aniž by se stalo něco zlověstného. Determinismus se do buildu zabudovává, nikdy se nedědí automaticky.

Projekt, který tvrdí reprodukovatelnost, musí pojmenovat normalizaci, kterou uplatňuje: pevná časová razítka, mapované cesty, seřazené položky archivu, připnuté verze kompilátoru a závislostí. Bez tohoto seznamu nelze odchylku interpretovat, protože prostor legitimní variace není definován.

Deklarované vstupy také musí být úplné. URL úložiště bez značky není revize, zamykací soubor bez hashe není sada závislostí a skript sestavení, který stahuje nástroj za běhu, má vstup, který nikdo nedokáže připnout. Každá mezera se později změní v rozdíl. Než cokoli porovnáte, seznam doplňte, protože neúplný seznam nemůže selhat způsobem, který něco znamená.

Co porovnání vlastně kontroluje

Nezávislá strana znovu sestaví v deklarovaném prostředí a porovná výstup se zveřejněným artefaktem. Bitová shoda je silná forma; dokumentovaný krok normalizace, při němž se zaznamenaný rozdíl zvrátí a výsledky pak souhlasí, je slabší, ale stále užitečná forma.

Porovnání se týká binárního souboru. Podpis odpovídá na jinou otázku: spojuje vydání s klíčem a klíč s identitou a projekt může mít platné podpisy nad artefakty, které nikdo nepřesestavil. Obě kontroly se sčítají, místo aby se nahrazovaly.

sha256sum wireguard-installer.msi
gpg --verify wireguard-installer.msi.sig wireguard-installer.msi

Spusťte obě před instalací a porovnejte hash s tím zveřejněným pro stejné vydání a platformu. Hash, který odpovídá stránce dodavatele, dokazuje, že stažený soubor dorazil neporušený; znovu sestavený binární soubor, který odpovídá zveřejněnému hashi dodavatele, dokazuje něco silnějšího o tom, jak vznikl.

Proč odchylka není důkazem manipulace

Většina odchylek pochází ze vstupu, který nikdo neřídil. Jiné vydání záplaty kompilátoru, cesta sestavení, která unikla do ladicích symbolů, lokalita, jež změnila pořadí řazení, nebo krok balení použitý po porovnání, to vše vytváří jiný hash než poctivá práce.

Proto je třeba odchylku číst proti dokumentovanému postupu, než se z ní stane příběh. Pokud postup vše připíná a rozdíl zůstává nevysvětlený, je to skutečné zjištění, které stojí za to projektu oznámit. Pokud postup o balení mlčí, rozdíl může být zcela očekávaný.

Symetrie je zde také důležitá: shoda nedokazuje, že zdrojový kód je bez vad, pouze že mu binární soubor odpovídá. Dobře auditovaný kód a reprodukovatelný kód jsou různé vlastnosti a projekt může mít jednu bez druhé.

Co tvrzení říká o službě za aplikací

Klient je program ve vašem zařízení; služba jsou servery, systémy účtů a zásady uchovávání jinde. Reprodukovatelnost omezuje první a o druhé neříká nic, ať je instalátor ověřen sebepečlivěji.

Konfigurace koncového bodu se může po instalaci také změnit, a to vzdáleným nastavením nebo profilem řízeným poskytovatelem. Tyto změny přicházejí po síti a nepokrývá je žádný hash, který jste vypočítali před připojením.

Čtěte tvrzení v jeho skutečném rozsahu a potom samostatně prověřte sousední otázku: co poskytovatel zaznamenává a podle jaké jurisdikce odpovídá na žádosti. Ověřený binární soubor a neověřená služba mohou existovat vedle sebe, a přesně takový případ má kontrola dodavatelského řetězce zviditelnit, ne opravit.