VPN-klient med åben kildekode: hvad koden beviser, og hvad den ikke kan

Kildekoden er offentliggjort, licensen er ren, og forbindelsen kan stadig ikke verificeres fra ende til anden. Det hul er almindeligt, og det er ikke en skandale. At offentliggøre kode gør én komponent undersøgelig for folk, der ikke blev inviteret, og det er en reel og usædvanlig egenskab. Det følger ikke, at den binære fil, du installerede, stammer fra den kode, eller at noget af det, udbyderen driver på den anden side, overhovedet er blevet gennemgået.

Adskil komponenten fra produktet

Fire ting kan bære open source-mærkatet, og de er sjældent alle åbne. Klientprogrammet er det, folk mener. Protokolimplementeringen nedenunder er et andet artefakt, nogle gange et bibliotek og nogle gange kode i træet. Serversoftwaren er det tredje, og udbyderens egen infrastruktur, kontoportal og supportværktøjer er det fjerde. Hver af dem kan være åben eller lukket uafhængigt.

Udsagn som "vores app er open source" beskriver derfor det første element og lader resten være ubehandlet, hvilket ikke er uærlighed så meget som et kategoriglid. Det nyttige spørgsmål er, hvilket lager, på hvilket tag, der svarer til den komponent, du stoler på.

Den sondring forklarer også, hvorfor to produkter med identiske åbne klienter kan tilbyde meget forskellige garantier. Klienten er den del, du kan kontrollere; operatørens adfærd er den del, du må vurdere på andre måder.

Match den installerede build med det offentliggjorte tag

Et lager er en registrering af hensigt; den binære fil på din disk er det, der kører. At lukke det hul er en mekanisk øvelse, og den begynder med at fastslå præcis, hvad der er installeret, frem for hvad downloadsiden reklamerede med.

Pakkemetadata fortæller dig versionen og oprindelsen, hvilket udelukker det trivielle tilfælde med en forældet eller udskiftet pakke. De fortæller dig ikke, hvordan pakken blev kompileret, og det er netop det spørgsmål, reproducerbare builds findes for at besvare. Reproducerbare builds lader en uafhængig part genopbygge fra samme kilde og sammenligne outputtet byte for byte, så en afvigelse bliver bevis i stedet for mistanke.

Selv et perfekt match beviser mindre, end folk håber. Det viser, at artefakten svarer til kilden og build-opskriften, ikke at kilden er fri for fejl, og ikke at den anvendte værktøjskæde var troværdig. Begge dele er værd at vide, men de er forskellige påstande.

dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wg

Hvor et symptom normalt begynder

Den klage, der giver anledning til denne læsning, er sjældent "koden er lukket". Den er normalt en konkret iagttagelse: en klient, der ringer et uventet sted hen, en version, der afviger fra udgivelsesnoterne, eller en supportproces, der spørger om mere, end tunnelen burde have brug for. Hvert af disse punkter peger på en anden komponent.

Uventet netværkstrafik fra klienten er et spørgsmål om klientens kildekode, og det kan besvares ved at læse den kodesti, der åbner forbindelsen. En versionsafvigelse er et spørgsmål om pakning. En supportproces, der anmoder om identitetsdokumenter, er et spørgsmål om kontosystemet, og ingen mængde klientrevision vil løse det.

At navngive komponenten gør en vag mistillid til en konkret kontrol. En konkret kontrol kan besvares, diskuteres eller lukkes. Alternativet er en permanent mistanke uden næste skridt.

Hvad gennemgangen ikke kan nå, og hvad man i stedet bør gøre

Opbevaring på udbyderens servere er uden for klientens rækkevidde. Det samme gælder adfærden i en faktureringsportal, en leverandør til svindelkontrol eller en supportdesk, der gemmer vedhæftede filer. En klientgennemgang, der strækkes til "vi har revideret tjenesten", fremsætter en påstand, som beviserne ikke understøtter.

Læs, hvad operatøren offentliggør om opbevaring og anmodninger, noter datoen, og behandl det som en erklæring fra en interesseret part frem for en måling. Det er en svagere form for bevis, og at være eksplicit om forskellen er mere nyttigt end at opgradere den i genfortællingen.

Brug derefter det, du har, som ét input blandt flere: identiteten på den installerede udgivelse, om softwaren vedligeholdes, hvordan klienten er konfigureret, og hvad operatøren siger om sine egne systemer. Åben kode styrker den vurdering på ét punkt. Den erstatter ikke resten.

En revisionspåstand bør altid navngive sine komponenter og versioner. Hvis en rapport ikke kan sige, hvilket lager og hvilken build den undersøgte, beskriver den en hensigt frem for et produkt.