VPN-klient med öppen källkod: vad koden bevisar och vad den inte kan
Ett offentligt arkiv är bevis om källkod, inte om bygget du installerade eller servrarna bakom det. Matcha utgåvan och bredda sedan granskningen.
Källkoden är publicerad, licensen är ren, och anslutningen kan fortfarande inte verifieras från ände till ände. Den luckan är vanlig och det är ingen skandal. Att publicera kod gör en komponent granskningsbar för människor som inte bjöds in, och det är en verklig och ovanlig egenskap. Det följer inte att binärfilen du installerade kommer från den koden, eller att något som leverantören kör på andra sidan alls har granskats.
Skilj komponenten från produkten
Fyra saker kan bära öppen källkod-etiketten, och sällan är alla öppna. Klientapplikationen är det folk menar. Protokollimplementeringen under den är en annan artefakt, ibland ett bibliotek och ibland kod i trädet. Serverprogramvaran är den tredje, och leverantörens egen infrastruktur, kontoportalen och supportverktygen är den fjärde. Var och en kan vara öppen eller stängd oberoende av de andra.
Därför beskriver påståenden som "vår app är öppen källkod" den första posten och lämnar resten obesvarat, vilket inte är oärlighet utan snarare en kategoriglidning. Den användbara frågan är vilket arkiv, vid vilken tagg, som motsvarar komponenten du förlitar dig på.
Den skillnaden förklarar också varför två produkter med identiska öppna klienter kan erbjuda mycket olika garantier. Klienten är den del du kan kontrollera; operatörens beteende är den del du måste bedöma på andra sätt.
Matcha det installerade bygget mot den publicerade taggen
Ett arkiv är en registrering av avsikt; binärfilen på din disk är det som körs. Att stänga den luckan är en mekanisk övning, och den börjar med att fastställa exakt vad som är installerat, inte vad nedladdningssidan annonserade.
| 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 |
Paketmetadata berättar versionen och ursprunget, vilket utesluter det triviala fallet med ett föråldrat eller utbytt paket. De berättar inte hur paketet kompilerades, och det är just den frågan reproducerbara byggen finns för att svara på. Reproducerbara byggen låter en oberoende part bygga om från samma källa och jämföra utdata byte för byte, så att en avvikelse blir bevis i stället för misstanke.
Även en perfekt matchning bevisar mindre än folk hoppas. Den visar att artefakten motsvarar källan och byggreceptet, inte att källan är felfri och inte att verktygskedjan som användes var pålitlig. Båda är värda att veta, men det är olika påståenden.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgVar ett symptom brukar börja
Klagomålet som föranleder den här läsningen är sällan "koden är stängd". Det är oftast en konkret observation: en klient som ringer någonstans oväntat, en version som skiljer sig från versionsanteckningarna, eller en supportprocess som ber om mer än tunneln borde behöva. Var och en av dessa punkter pekar på en annan komponent.
Oväntad nätverkstrafik från klienten är en fråga om klientens källkod, och den kan besvaras genom att läsa kodvägen som öppnar anslutningen. En versionsavvikelse är en fråga om paketering. En supportprocess som begär identitetshandlingar är en fråga om kontosystemet, och ingen klientgranskning kommer att lösa den.
Att namnge komponenten förvandlar en vag misstro till en konkret kontroll. En konkret kontroll kan besvaras, diskuteras eller avslutas. Alternativet är en permanent misstanke utan nästa steg.
Vad granskningen inte kan nå, och vad man i stället bör göra
Lagring på leverantörens servrar ligger utanför klientens räckvidd. Det gör också beteendet hos en faktureringsportal, en leverantör för bedrägerikontroll eller en supportdesk som behåller bilagor. En klientgranskning som sträcks ut till "vi granskade tjänsten" gör ett påstående som bevisen inte stöder.
Läs vad operatören publicerar om lagring och förfrågningar, notera datumet och behandla det som ett uttalande från en intresserad part snarare än en mätning. Det är en svagare form av bevis, och att vara tydlig om skillnaden är mer användbart än att uppgradera den i återberättandet.
Använd sedan det du har som en av flera ingångar: identiteten hos den installerade utgåvan, om programvaran underhålls, hur klienten är konfigurerad och vad operatören säger om sina egna system. Öppen kod stärker den bedömningen på en punkt. Den ersätter inte resten.
Ett revisionspåstående bör alltid namnge sina komponenter och versioner. Om en rapport inte kan säga vilket arkiv och vilket bygge den undersökte, beskriver den en avsikt snarare än en produkt.