VPN-klient med åpen kildekode: hva koden beviser, og hva den ikke kan
Et offentlig depot er bevis om kildekode, ikke om bygget du installerte eller serverne bak det. Match utgivelsen, og utvid deretter gjennomgangen.
Kildekoden er publisert, lisensen er ren, og tilkoblingen kan fortsatt ikke verifiseres fra ende til annen. Det gapet er vanlig, og det er ikke en skandale. Å publisere kode gjør én komponent etterprøvbar for folk som ikke ble invitert, og det er en reell og uvanlig egenskap. Det følger ikke at binærfilen du installerte kommer fra den koden, eller at noe leverandøren kjører på den andre siden i det hele tatt er gjennomgått.
Skill komponenten fra produktet
Fire ting kan bære åpen kildekode-merket, og sjelden er alle åpne. Klientapplikasjonen er det folk mener. Protokollimplementeringen under den er et annet artefakt, noen ganger et bibliotek og noen ganger kode i treet. Serverprogramvaren er den tredje, og leverandørens egen infrastruktur, kontoportalen og støtteverktøyene er den fjerde. Hver av dem kan være åpen eller lukket uavhengig.
Derfor beskriver utsagn som "appen vår er åpen kildekode" det første elementet og lar resten stå ubesvart, noe som ikke er uærlighet så mye som en kategoriglidning. Det nyttige spørsmålet er hvilket depot, på hvilken tag, som svarer til komponenten du er avhengig av.
Den forskjellen forklarer også hvorfor to produkter med identiske åpne klienter kan tilby svært ulike garantier. Klienten er delen du kan kontrollere; operatørens atferd er delen du må vurdere på andre måter.
Match det installerte bygget med den publiserte taggen
Et depot er en registrering av intensjon; binærfilen på disken din er det som kjører. Å lukke det gapet er en mekanisk øvelse, og den begynner med å fastslå nøyaktig hva som er installert, ikke hva nedlastingssiden 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 |
Pakkemetadata forteller deg versjonen og opprinnelsen, noe som utelukker det trivielle tilfellet med en utdatert eller erstattet pakke. De forteller deg ikke hvordan pakken ble kompilert, og nettopp det spørsmålet finnes reproduserbare bygg for å svare på. Reproduserbare bygg lar en uavhengig part bygge på nytt fra samme kilde og sammenligne resultatet byte for byte, slik at et avvik blir bevis i stedet for mistanke.
Selv en perfekt match beviser mindre enn folk håper. Det viser at artefakten svarer til kilden og byggoppskriften, ikke at kilden er feilfri, og ikke at verktøykjeden som ble brukt var pålitelig. Begge er verdt å vite, men det er ulike påstander.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgHvor et symptom vanligvis starter
Klagen som utløser denne lesningen er sjelden "koden er lukket". Den er vanligvis en konkret observasjon: en klient som ringer et uventet sted, en versjon som avviker fra utgivelsesnotatene, eller en støtteprosess som ber om mer enn tunnelen skulle trenge. Hvert av disse punktene peker på en annen komponent.
Uventet nettverkstrafikk fra klienten er et spørsmål om klientens kildekode, og det kan besvares ved å lese kodebanen som åpner tilkoblingen. Et versjonsavvik er et spørsmål om pakking. En støtteprosess som ber om identitetsdokumenter er et spørsmål om kontosystemet, og ingen klientrevisjon vil løse det.
Å navngi komponenten gjør en vag mistillit om til en konkret sjekk. En konkret sjekk kan besvares, diskuteres eller lukkes. Alternativet er en permanent mistanke uten neste steg.
Hva gjennomgangen ikke kan nå, og hva du bør gjøre i stedet
Oppbevaring på leverandørens servere er utenfor klientens rekkevidde. Det samme gjelder atferden til en faktureringsportal, en leverandør for svindelkontroll eller en støttedisk som beholder vedlegg. En klientgjennomgang som strekkes til "vi reviderte tjenesten" gir en påstand som bevisene ikke støtter.
Les hva operatøren publiserer om oppbevaring og forespørsler, noter datoen, og behandle det som en erklæring fra en interessert part framfor en måling. Det er en svakere form for bevis, og å være tydelig om forskjellen er mer nyttig enn å oppgradere den i gjenfortellingen.
Bruk deretter det du har som én av flere innganger: identiteten til den installerte utgivelsen, om programvaren vedlikeholdes, hvordan klienten er konfigurert, og hva operatøren sier om sine egne systemer. Åpen kode styrker den vurderingen på ett punkt. Den erstatter ikke resten.
En revisjonspåstand bør alltid navngi komponentene og versjonene sine. Hvis en rapport ikke kan si hvilket depot og hvilket bygg den undersøkte, beskriver den en intensjon framfor et produkt.