Reprodukálható buildek VPN-alkalmazásokhoz: mit bizonyít az egyezés
Az egyező újraépítés egy terjesztett binárist köt a deklarált forráskódhoz és eszközökhöz. Semmit sem mond az adott bináris mögötti VPN-szolgáltatásról vagy annak naplóiról.
A reprodukálhatóság az ellátási lánc tulajdonsága: ugyanazoknak a deklarált bemeneteknek ugyanazt az artefaktumot kell előállítaniuk. Egy VPN-kliens esetében ez az állítás a letöltött telepítőt ahhoz a forráskódhoz és eszközlánchoz köti, amelyet bárki újraépíthet. Semmit sem mond arról a szolgáltatásról, amelyhez a kliens csatlakozik.
A hasznos kérdés ezért szűk és megválaszolható. Közzétesz-e a projekt egy eljárást, és megfelel-e neki a te konkrét artefaktumod?
Ahol egy build megszűnik determinisztikusnak lenni
A fordítók időbélyegeket, abszolút útvonalakat és build-gazdagépek neveit ágyazzák be, hacsak nem tiltják meg nekik. Az archívumok rögzítik a fájlok sorrendjét és módosítási idejét, a linkerek az eszközlánc verziójával változtatják kimenetüket, és a párhuzamos tömörítés átrendezheti a blokkokat. Bármelyikük miatt két azonos forrásból készült build bájtokban eltér, anélkül hogy bármi baljós történne. A determinizmust beletervezik a buildbe, soha nem öröklődik alapértelmezésként.
Az a projekt, amely reprodukálhatóságot állít, köteles megnevezni az alkalmazott normalizálást: rögzített időbélyegek, leképezett útvonalak, rendezett archívumbejegyzések, rögzített fordító- és függőségverziók. E lista nélkül egy eltérés nem értelmezhető, mert a legitim variáció tere definiálatlan.
A deklarált bemeneteknek is teljeseknek kell lenniük. Egy címke nélküli tároló-URL nem revízió, egy hash nélküli zárolási fájl nem függőségi halmaz, és egy olyan build-szkriptnek, amely futásidőben tölt le egy eszközt, olyan bemenete van, amelyet senki sem tud rögzíteni. Minden hézag később különbséggé válik. Bármi összehasonlítása előtt fejezd be a listát, mert egy hiányos lista nem tud olyan módon meghiúsulni, amelynek értelme van.
| Input | How it drifts | What pins it |
|---|---|---|
| Source | Branch moves after release | Commit hash in the build metadata |
| Toolchain | Compiler patch level differs | Container image digest |
| Packaging | Archive order and mtimes vary | Normalised archive settings |
Mit ellenőriz valójában az összehasonlítás
Egy független fél újraépít a deklarált környezetben, és összehasonlítja a kimenetet a közzétett artefaktummal. A bitre azonos eredmény az erős forma; egy dokumentált normalizálási lépés, amelyben egy rögzített eltérést visszafordítanak, és az eredmények ezután megegyeznek, a gyengébb, de még mindig hasznos forma.
Az összehasonlítás a binárisról szól. Az aláírás más kérdésre válaszol: egy kiadást kulcshoz, a kulcsot pedig identitáshoz köt, és egy projektnek lehetnek érvényes aláírásai olyan artefaktumokon, amelyeket senki sem épített újra. A két ellenőrzés egymásra rakódik, ahelyett hogy helyettesítenék egymást.
sha256sum wireguard-installer.msi gpg --verify wireguard-installer.msi.sig wireguard-installer.msi
Telepítés előtt futtasd mindkettőt, és hasonlítsd össze a hash-t az ugyanahhoz a kiadáshoz és platformhoz közzétett értékkel. A szállító oldalával egyező hash bizonyítja, hogy a letöltés sértetlenül megérkezett; egy újraépített bináris, amely egyezik a szállító közzétett hash-ével, valami erősebbet bizonyít arról, hogyan készült.
Miért nem bizonyíték a manipulációra az eltérés
A legtöbb eltérés olyan bemenetből származik, amelyet senki sem ellenőrzött. Egy másik fordítói javítási kiadás, a hibakeresési szimbólumokba szivárgott build-útvonal, a rendezési sorrendet megváltoztató területi beállítás, vagy az összehasonlítás után alkalmazott csomagolási lépés mind más hash-t ad, mint a becsületes munka.
Ezért az eltérést a dokumentált eljárás ellenében kell olvasni, mielőtt történetté válik. Ha az eljárás mindent rögzít, és a különbség megmagyarázatlan marad, az valódi lelet, amelyet érdemes a projekt elé tárni. Ha az eljárás hallgat a csomagolásról, a különbség teljesen várható lehet.
A szimmetria itt is számít: az egyezés nem bizonyítja, hogy a forráskód hibamentes, csak azt, hogy a bináris megfelel neki. A jól auditált kód és a reprodukálható kód különböző tulajdonságok, és egy projekt birtokolhatja az egyiket a másik nélkül.
Mit mond az állítás az alkalmazás mögötti szolgáltatásról
A kliens egy program az eszközödön; a szolgáltatás máshol lévő szerverek, fiókrendszerek és megőrzési szabályzatok. A reprodukálhatóság az elsőt korlátozza, a másodikról semmit sem mond, akármilyen gondosan ellenőrzik a telepítőt.
A végpont konfigurációja telepítés után is változhat, távoli beállításokon vagy a szolgáltató által vezérelt profilon keresztül. Ezek a változások a hálózaton keresztül érkeznek, és nem fedi le őket semmilyen hash, amelyet a csatlakozás előtt számítottál.
Olvasd az állítást a tényleges hatókörében, majd külön ellenőrizd a szomszédos kérdést: mit rögzít a szolgáltató, és melyik joghatóság alatt válaszol a kérésekre. Egy ellenőrzött bináris és egy ellenőrizetlen szolgáltatás együtt létezhet, és pontosan ezt az esetet hivatott láthatóvá tenni az ellátási lánc ellenőrzése, nem pedig megjavítani.