Kliyenteng VPN na open source: ano ang pinapatunayan ng code at ano ang hindi
Ang pampublikong repositoryo ay ebidensya tungkol sa source code, hindi tungkol sa build na inilagay mo o sa mga server sa likod nito. Itugma ang release, pagkatapos palawakin ang pagsusuri.
Nailathala ang source, malinis ang lisensya, at hindi pa rin ma-verify ang koneksyon mula simula hanggang dulo. Karaniwan ang agwat na iyon, at hindi ito iskandalo. Ang paglathala ng code ay ginagawang masuri ng mga taong hindi inimbita ang isang bahagi, at iyon ay tunay at di-karaniwang katangian. Hindi ito nangangahulugan na ang binary na inilagay mo ay nagmula sa code na iyon, o na anumang pinapatakbo ng provider sa kabilang panig ay nasuri na.
Ihiwalay ang bahagi sa produkto
Apat na bagay ang maaaring magdala ng tatak na open source, at bihirang bukas ang lahat. Ang kliyenteng aplikasyon ang tinutukoy ng mga tao. Ang implementasyon ng protocol sa ilalim nito ay ibang artifact, kung minsan library at kung minsan code sa loob ng puno. Ang server software ang pangatlo, at ang sariling imprastruktura ng provider, portal ng account at mga kasangkapan sa suporta ang pang-apat. Bawat isa ay maaaring bukas o sarado nang mag-isa.
Kaya ang mga pahayag na "open source ang app namin" ay naglalarawan ng unang aytem at iniiwan ang iba na walang sagot, na hindi kawalan ng katapatan kundi paglihis ng kategorya. Ang kapaki-pakinabang na tanong ay aling repositoryo, sa aling tag, ang tumutugma sa bahaging inaasahan mo.
Ipinapaliwanag din ng pagkakaibang iyon kung bakit ang dalawang produkto na may parehong bukas na kliyente ay makapag-aalok ng magkaibang garantiya. Ang kliyente ang bahaging masusuri mo; ang pag-uugali ng operator ang bahaging kailangan mong tasahin sa ibang paraan.
Itugma ang naka-install na build sa nailathalang tag
Ang repositoryo ay talaan ng layunin; ang binary sa iyong disk ang tumatakbo. Ang pagsasara ng agwat na iyon ay mekanikal na pagsasanay, at nagsisimula ito sa pagtukoy nang eksakto kung ano ang naka-install, hindi ang inanunsyo ng pahina ng download.
| Component | What inspection can show | What it leaves untouched |
|---|---|---|
| Client source | How profiles, packets and optional telemetry are handled | Whether the shipped binary matches that source |
| Build output | Whether a declared build reproduces a matching artefact | Whether the source is correct or the toolchain is clean |
| Server software | What the implementation is capable of logging | What the operator actually configures and retains |
| Account and support systems | Almost nothing, unless they are separately published | Everything about how those systems treat your data |
Sinasabi ng metadata ng pakete ang bersyon at pinagmulan, na nag-aalis ng simpleng kaso ng lipas o pinalitang pakete. Hindi nito sinasabi kung paano na-compile ang pakete, at doon mismo may mga build na maaaring kopyahin. Mga build na maaaring kopyahin pinapayagan ang isang malayang partido na muling buuin mula sa parehong source at ihambing ang output byte sa byte, kaya nagiging ebidensya ang pagkakaiba at hindi hinala.
Kahit ang perpektong tugma ay nagpapatunay ng mas mababa kaysa inaasahan ng mga tao. Ipinapakita nito na tumutugma ang artifact sa source at sa recipe ng build, hindi na walang depekto ang source at hindi na mapagkakatiwalaan ang toolchain na ginamit. Kapwa sulit malaman, ngunit magkaibang pahayag ang mga ito.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgSaan karaniwang nagsisimula ang sintomas
Ang reklamong nag-uudyok sa pagbasang ito ay bihirang "sarado ang code". Karaniwan itong partikular na obserbasyon: kliyenteng tumatawag sa hindi inaasahang lugar, bersyong iba sa mga tala ng release, o proseso ng suporta na humihingi ng higit sa dapat kailanganin ng tunnel. Bawat isa sa mga puntong ito ay tumutukoy sa ibang bahagi.
Ang hindi inaasahang trapiko sa network mula sa kliyente ay tanong tungkol sa source code ng kliyente, at masasagot ito sa pagbabasa ng code path na nagbubukas ng koneksyon. Ang pagkakaiba ng bersyon ay tanong tungkol sa packaging. Ang proseso ng suporta na humihingi ng mga dokumento ng pagkakakilanlan ay tanong tungkol sa sistema ng account, at walang anumang pag-audit ng kliyente ang makakalutas nito.
Ang pagpangalan sa bahagi ay ginagawang partikular na pagsusuri ang malabong pag-aalinlangan. Ang partikular na pagsusuri ay masasagot, mapagtatalunan o maisasara. Ang alternatibo ay permanenteng hinala na walang susunod na hakbang.
Ano ang hindi naaabot ng pagsusuri, at ano ang dapat gawin sa halip
Ang pagtatago sa mga server ng provider ay wala sa abot ng kliyente. Gayundin ang pag-uugali ng portal ng pagsingil, ng vendor na nagsusuri ng panloloko o ng desk ng suporta na nag-iingat ng mga attachment. Ang pagsusuri ng kliyente na hinahatak hanggang sa "inaudit namin ang serbisyo" ay gumagawa ng pahayag na hindi sinusuportahan ng ebidensya.
Basahin ang inilalathala ng operator tungkol sa pagtatago at mga kahilingan, itala ang petsa, at ituring itong pahayag ng isang partidong may interes at hindi pagsukat. Iyon ay mas mahinang uri ng ebidensya, at ang maging malinaw tungkol sa pagkakaiba ay mas kapaki-pakinabang kaysa itaas ito sa muling pagkukuwento.
Pagkatapos gamitin ang mayroon ka bilang isa sa ilang input: ang pagkakakilanlan ng naka-install na release, kung pinapanatili ang software, kung paano naka-configure ang kliyente, at ano ang sinasabi ng operator tungkol sa sarili nitong mga sistema. Ang bukas na code ay nagpapalakas sa pagtatasa na iyon sa isang punto. Hindi nito pinapalitan ang iba.
Ang pahayag ng pag-audit ay dapat laging magpangalan ng mga bahagi at bersyon nito. Kung hindi masabi ng ulat kung aling repositoryo at aling build ang sinuri, inilalarawan nito ang layunin at hindi produkto.