Nyílt forráskódú VPN-kliens: mit bizonyít a kód, és mit nem
Egy nyilvános tároló a forráskódról szóló bizonyíték, nem a telepített buildről vagy az mögötte lévő szerverekről. Egyeztesse a kiadást, majd szélesítse a vizsgálatot.
A forrás közzétéve, a licenc tiszta, és a kapcsolat továbbra sem ellenőrizhető végponttól végpontig. Ez a rés megszokott, és nem botrány. A kód közzététele egy komponenst olyan emberek számára is vizsgálhatóvá tesz, akiket nem hívtak meg, és ez valós és szokatlan tulajdonság. Ebből nem következik, hogy a telepített bináris ebből a kódból származik, vagy hogy a szolgáltató által a másik oldalon működtetett bármi egyáltalán átvizsgálásra került.
Válassza külön a komponenst a terméktől
Négy dolog viselheti a nyílt forráskód címkét, és ritkán nyílt mindegyik. Az ügyfélalkalmazás az, amire az emberek gondolnak. Az alatta lévő protokollmegvalósítás más artefaktum, néha könyvtár, néha a fában lévő kód. A szerver szoftver a harmadik, a szolgáltató saját infrastruktúrája, fiókportálja és támogató eszközei pedig a negyedik. Mindegyik lehet nyílt vagy zárt, egymástól függetlenül.
Ezért az olyan kijelentések, mint hogy "az alkalmazásunk nyílt forráskódú", az első elemet írják le, a többit pedig válasz nélkül hagyják, ami nem tisztességtelenség, hanem inkább kategóriacsúszás. A hasznos kérdés az, melyik tároló, melyik címkén felel meg annak a komponensnek, amelyre támaszkodik.
Ez a megkülönböztetés azt is megmagyarázza, miért kínálhat két azonos nyílt klienssel rendelkező termék nagyon eltérő biztosítékokat. A kliens az a rész, amelyet ellenőrizhet; az üzemeltető viselkedése az a rész, amelyet más eszközökkel kell megítélnie.
Egyeztesse a telepített buildet a közzétett címkével
A tároló a szándék nyilvántartása; a lemezen lévő bináris az, ami fut. Ennek a résnek a bezárása mechanikus gyakorlat, és azzal kezdődik, hogy pontosan azonosítjuk, mi van telepítve, nem azzal, mit hirdetett a letöltési oldal.
| 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 |
A csomag metaadatai megadják a verziót és az eredetet, ami kizárja az elavult vagy helyettesített csomag egyszerű esetét. Azt viszont nem mondják meg, hogyan fordították a csomagot, és pontosan erre a kérdésre léteznek a reprodukálható buildek. Reprodukálható buildek lehetővé teszik, hogy egy független fél ugyanabból a forrásból újraépítsen, és bájtról bájtra összehasonlítsa a kimenetet, így az eltérés bizonyítékká válik a gyanú helyett.
Még a tökéletes egyezés is kevesebbet bizonyít, mint amit az emberek remélnek. Azt mutatja, hogy az artefaktum megfelel a forrásnak és a build-receptnek, nem azt, hogy a forrás hibátlan, és nem azt, hogy a használt eszközlánc megbízható volt. Mindkettő tudásra érdemes, de ezek különböző állítások.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgHol kezdődik általában a tünet
Az olvasást kiváltó panasz ritkán az, hogy "a kód zárt". Általában konkrét megfigyelés: egy kliens, amely valahová váratlanul telefonál, egy verzió, amely eltér a kiadási jegyzetektől, vagy egy támogatási folyamat, amely többet kér, mint amennyire az alagútnak szüksége lehetne. Mindegyik pont más komponensre mutat.
A kliens váratlan hálózati forgalma a kliens forráskódjának kérdése, és megválaszolható a kapcsolatot megnyitó kódútvonal olvasásával. A verzióeltérés csomagolási kérdés. Az igazolványokat kérő támogatási folyamat a fiókrendszer kérdése, és semmilyen kliensaudit nem oldja meg.
A komponens megnevezése a homályos bizalmatlanságot konkrét ellenőrzéssé alakítja. Egy konkrét ellenőrzés megválaszolható, megvitatható vagy lezárható. Az alternatíva az állandó gyanú következő lépés nélkül.
Mit nem érhet el a vizsgálat, és mit tegyünk helyette
A szolgáltató szerverein történő megőrzés kívül esik a kliens hatókörén. Ugyanez vonatkozik egy számlázási portál, egy csalásellenőrző szolgáltató vagy a mellékleteket megőrző támogatás viselkedésére. A kliensvizsgálat, amelyet kifeszítenek addig, hogy "auditáltuk a szolgáltatást", olyan állítást tesz, amelyet a bizonyítékok nem támasztanak alá.
Olvassa el, mit tesz közzé az üzemeltető a megőrzésről és a kérelmekről, jegyezze fel a dátumot, és kezelje érdekelt fél nyilatkozataként, nem mérésként. Ez a bizonyíték gyengébb formája, és a különbség kimondása hasznosabb, mint felnagyítani az újramondásban.
Ezután használja fel azt, amije van, egy bemenetként a többiek mellett: a telepített kiadás azonossága, hogy karbantartják-e a szoftvert, hogyan van beállítva a kliens, és mit mond az üzemeltető a saját rendszereiről. A nyílt kód egy ponton megerősíti ezt az értékelést. Nem helyettesíti a többit.
Az auditállításnak mindig meg kell neveznie a komponenseit és verzióit. Ha egy jelentés nem tudja megmondani, melyik tárolót és melyik buildet vizsgálta, akkor szándékot ír le, nem terméket.