Mga build na maaaring muling gawin para sa mga VPN app: ano ang pinapatunayan ng tugma
Ang tugmang muling pagbuo ay nag-uugnay ng ipinamahaging binary sa idineklarang source at mga kasangkapan. Wala itong sinasabi tungkol sa serbisyong VPN sa likod ng binary na iyon o sa mga log nito.
Ang muling paggawa ay isang katangian ng supply chain: ang parehong idineklarang input ay dapat gumawa ng parehong artifact. Para sa isang VPN client, iniuugnay ng pahayag na iyon ang installer na inilunsad mo sa source at toolchain na kahit sino ay makakabuo muli. Wala itong sinasabi tungkol sa serbisyong kinokonektahan ng client.
Kaya ang kapaki-pakinabang na tanong ay makitid at masasagot. Naglalathala ba ang proyekto ng pamamaraan, at tumutugma ba rito ang iyong partikular na artifact?
Saan tumitigil ang isang build na maging deterministiko
Naglalagay ang mga compiler ng timestamp, ganap na landas at pangalan ng build host maliban kung ipagbawal. Itinatala ng mga archive ang pagkakasunod-sunod ng file at oras ng pagbabago, nagbabago ang output ng mga linker ayon sa bersyon ng toolchain, at ang parallel na kompresyon ay maaaring muling mag-ayos ng mga bloke. Alinman sa mga ito ay nagpapabago sa byte ng dalawang build mula sa parehong source nang walang anumang nakakatakot na nangyari. Ang determinismo ay inilalagay sa build sa pamamagitan ng inhenyeriya, hindi kailanman namamana bilang default.
Ang proyektong nagsasabing maaaring muling gawin ay kailangang pangalanan ang normalisasyong ginagamit: nakapirming timestamp, naka-map na landas, inayos na archive entry, at nakapirming bersyon ng compiler at dependencies. Kung wala ang listahang iyon, hindi matutukoy ang pagkakaiba, dahil hindi tinukoy ang espasyo ng lehitimong pagkakaiba-iba.
Ang idineklarang input ay kailangan ding kumpleto. Ang URL ng repository na walang tag ay hindi rebisyon, ang lock file na walang hash ay hindi set ng dependencies, at ang build script na nagda-download ng kasangkapan sa oras ng pagpapatakbo ay may input na walang makapagpipin. Bawat puwang ay nagiging pagkakaiba sa hinaharap. Kumpletuhin ang listahan bago ihambing ang anuman, dahil ang kulang na listahan ay hindi maaaring mabigo sa paraang may kahulugan.
| 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 |
Ano ang aktwal na sinusuri ng paghahambing
Ang isang malayang partido ay bumubuo muli sa idineklarang kapaligiran at inihahambing ang output sa inilathalang artifact. Ang bit-identikal ang malakas na anyo; ang dokumentadong hakbang ng normalisasyon, kung saan binabaligtad ang naitalang pagkakaiba at pagkatapos ay tumutugma ang mga resulta, ang mas mahinang anyo ngunit kapaki-pakinabang pa rin.
Ang paghahambing ay tungkol sa binary. Ang lagda ay sumasagot sa ibang tanong: iniuugnay nito ang isang release sa isang susi at ang susi sa isang pagkakakilanlan, at ang isang proyekto ay maaaring may wastong lagda sa mga artifact na wala pang nakabuo muli. Nagpapatong ang dalawang pagsusuri sa halip na magpalitan.
sha256sum wireguard-installer.msi gpg --verify wireguard-installer.msi.sig wireguard-installer.msi
Patakbuhin ang pareho bago mag-install, at ihambing ang hash sa inilathala para sa parehong release at platform. Ang hash na tumutugma sa pahina ng vendor ay nagpapatunay na dumating nang buo ang download; ang muling nabuong binary na tumutugma sa inilathalang hash ng vendor ay nagpapatunay ng mas malakas tungkol sa kung paano ito ginawa.
Bakit ang pagkakaiba ay hindi patunay ng pakikialam
Karamihan ng pagkakaiba ay nagmumula sa input na walang kumontrol. Ibang patch release ng compiler, landas ng build na tumagas sa mga simbolo ng debug, lokal na nagbago ng pagkakasunod-sunod, o hakbang ng packaging na inilapat pagkatapos ng paghahambing — lahat ay gumagawa ng ibang hash kaysa sa tapat na gawain.
Kaya ang pagkakaiba ay dapat basahin laban sa dokumentadong pamamaraan bago ito maging kuwento. Kung ang pamamaraan ay nagpipin sa lahat at nananatiling hindi maipaliwanag ang pagkakaiba, iyon ay tunay na natuklasan na karapat-dapat iharap sa proyekto. Kung ang pamamaraan ay tahimik tungkol sa packaging, maaaring inaasahan lamang ang pagkakaiba.
Mahalaga rin ang simetriya dito: hindi pinatutunayan ng tugma na walang depekto ang source, pinatutunayan lamang na tumutugma rito ang binary. Ang mahusay na na-audit na code at ang code na maaaring muling gawin ay magkaibang katangian, at ang isang proyekto ay maaaring magkaroon ng isa nang wala ang isa.
Ano ang sinasabi ng pahayag tungkol sa serbisyo sa likod ng app
Ang client ay isang programa sa iyong device; ang serbisyo ay mga server, sistema ng account at patakaran ng pagpapanatili sa ibang lugar. Nililimitahan ng muling paggawa ang una at wala itong sinasabi tungkol sa pangalawa, gaano man kaingat na beripikahin ang installer.
Maaaring magbago rin ang configuration ng endpoint pagkatapos ng pag-install, sa pamamagitan ng remote na setting o profile na kontrolado ng provider. Dumarating ang mga pagbabagong iyon sa network at hindi saklaw ng anumang hash na kinakalkula mo bago kumonekta.
Basahin ang pahayag sa tunay nitong saklaw, pagkatapos ay suriin nang hiwalay ang katabing tanong: ano ang itinatala ng provider, at sa ilalim ng aling hurisdiksyon ito sumasagot sa mga kahilingan. Ang beripikadong binary at ang hindi beripikadong serbisyo ay maaaring magkasamang umiral, at iyon mismo ang kaso na idinisenyo ng pagsusuri ng supply chain na gawing nakikita, hindi ayusin.