VPN-klient med open kjeldekode: kva koden beviser, og kva han ikkje kan
Eit offentleg depot er prov på kjeldekode, ikkje på bygget du installerte eller tenarane bak det. Match utgivinga, og utvid deretter gjennomgangen.
Kjeldekoden er publisert, lisensen er rein, og sambandet kan framleis ikkje stadfestast frå ende til annan. Det gapet er vanleg, og det er ikkje ein skandale. Å publisere kode gjer éin komponent etterprøvbar for folk som ikkje vart inviterte, og det er ein reell og uvanleg eigenskap. Det følgjer ikkje at binærfilen du installerte kjem frå den koden, eller at noko leverandøren køyrer på den andre sida i det heile er gjennomgått.
Skil komponenten frå produktet
Fire ting kan bera open kjeldekode-merket, og sjeldan er alle opne. Klientapplikasjonen er det folk meiner. Protokollimplementasjonen under han er eit anna artefakt, stundom eit bibliotek og stundom kode i treet. Tenarprogramvara er den tredje, og leverandøren sin eigen infrastruktur, kontoportalen og støtteverktøya er den fjerde. Kvar av dei kan vera open eller lukka uavhengig.
Difor skildrar utsegner som "appen vår er open kjeldekode" det første elementet og lèt resten stå ubesvara, noko som ikkje er uærlegdom så mykje som ein kategoriglidnad. Det nyttige spørsmålet er kva depot, på kva tag, som svarar til komponenten du er avhengig av.
Den skilnaden forklarar òg kvifor to produkt med identiske opne klientar kan tilby svært ulike garantiar. Klienten er delen du kan kontrollere; åtferda til operatøren er delen du må vurdere på andre måtar.
Match det installerte bygget med den publiserte taggen
Eit depot er ei registrering av intensjon; binærfilen på disken din er det som køyrer. Å lukke det gapet er ei mekanisk øving, og ho byrjar med å fastslå nøyaktig kva som er installert, ikkje kva nedlastingssida annonserte.
| 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 |
Pakke-metadata fortel deg versjonen og opphavet, noko som utelukkar det trivielle tilfellet med ein utdatert eller erstatta pakke. Dei fortel deg ikkje korleis pakken vart kompilert, og nettopp det spørsmålet finst reproduserbare bygg for å svare på. Reproduserbare bygg lèt ein uavhengig part byggje på nytt frå same kjelde og samanlikne resultatet byte for byte, slik at eit avvik blir prov i staden for mistanke.
Sjølv ein perfekt match beviser mindre enn folk håpar. Det viser at artefakten svarar til kjelda og byggjeoppskrifta, ikkje at kjelda er feilfri, og ikkje at verktøykjeda som vart brukt var påliteleg. Begge er verdt å vite, men det er ulike påstandar.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgKvar eit symptom vanlegvis byrjar
Klaga som utløyser denne lesinga er sjeldan "koden er lukka". Ho er vanlegvis ei konkret observasjon: ein klient som ringjer ein uventa stad, ein versjon som avvik frå utgivingsnotata, eller ein støtteprosess som ber om meir enn tunnelen skulle trenge. Kvart av desse punkta peikar på ein annan komponent.
Uventa nettverkstrafikk frå klienten er eit spørsmål om kjeldekoden til klienten, og det kan svarast på ved å lese kodebana som opnar sambandet. Eit versjonsavvik er eit spørsmål om pakking. Ein støtteprosess som ber om identitetsdokument er eit spørsmål om kontosystemet, og ingen klientrevisjon vil løyse det.
Å namngje komponenten gjer ein vag mistillit om til ein konkret sjekk. Ein konkret sjekk kan svarast på, diskuterast eller lukkast. Alternativet er ein permanent mistanke utan neste steg.
Kva gjennomgangen ikkje kan nå, og kva du bør gjere i staden
Oppbevaring på tenarane til leverandøren er utanfor rekkjevidda til klienten. Det same gjeld åtferda til ein faktureringsportal, ein leverandør for svindelkontroll eller ein støttedisk som held på vedlegg. Ein klientgjennomgang som blir strekt til "vi reviderte tenesta" gir ein påstand som prova ikkje støttar.
Les kva operatøren publiserer om oppbevaring og førespurnader, noter datoen, og handsam det som ei fråsegn frå ein interessert part framfor ei måling. Det er ei svakare form for prov, og å vere tydeleg om skilnaden er meir nyttig enn å oppgradere han i attforteljinga.
Bruk deretter det du har som éin av fleire inngangar: identiteten til den installerte utgivinga, om programvara blir vedlikehalden, korleis klienten er konfigurert, og kva operatøren seier om sine eigne system. Open kode styrkjer den vurderinga på eitt punkt. Han erstattar ikkje resten.
Ein revisjonspåstand bør alltid namngje komponentane og versjonane sine. Viss ein rapport ikkje kan seie kva depot og kva bygg han undersøkte, skildrar han ein intensjon framfor eit produkt.