Open-source-VPN-client: wat de code bewijst en wat niet
Een openbare repository is bewijs over broncode, niet over de build die u installeerde of de servers erachter. Koppel de release en verbreed daarna de beoordeling.
De bron is gepubliceerd, de licentie is schoon, en de verbinding is nog steeds niet van begin tot eind te verifiëren. Die kloof is gewoon en het is geen schandaal. Code publiceren maakt één component inspecteerbaar door mensen die niet waren uitgenodigd, en dat is een echte en ongebruikelijke eigenschap. Daaruit volgt niet dat het binaire bestand dat u installeerde uit die code komt, of dat iets wat de provider aan de andere kant draait überhaupt is beoordeeld.
Scheid het onderdeel van het product
Vier dingen kunnen het open-source-label dragen, en zelden zijn ze allemaal open. De clientapplicatie is wat mensen bedoelen. De protocolimplementatie eronder is een ander artefact, soms een bibliotheek en soms code in de boom. De serversoftware is de derde, en de eigen infrastructuur van de provider, het accountportaal en de ondersteuningstools zijn de vierde. Elk kan onafhankelijk open of gesloten zijn.
Uitspraken als "onze app is open source" beschrijven dus het eerste item en laten de rest onbeantwoord, wat geen oneerlijkheid is maar eerder een categorieverschuiving. De nuttige vraag is welke repository, op welke tag, overeenkomt met het onderdeel waarop u vertrouwt.
Dat onderscheid verklaart ook waarom twee producten met identieke open clients heel verschillende garanties kunnen bieden. De client is het deel dat u kunt controleren; het gedrag van de operator is het deel dat u met andere middelen moet beoordelen.
Koppel de geïnstalleerde build aan de gepubliceerde tag
Een repository is een registratie van bedoeling; het binaire bestand op uw schijf is wat draait. Die kloof dichten is een mechanische oefening, en die begint met vaststellen wat er precies is geïnstalleerd, niet wat de downloadpagina adverteerde.
| 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 |
Pakketmetadata vertellen u de versie en de herkomst, wat het triviale geval van een verouderd of vervangen pakket uitsluit. Ze vertellen u niet hoe dat pakket is gecompileerd, en precies die vraag bestaan reproduceerbare builds om te beantwoorden. Reproduceerbare builds stellen een onafhankelijke partij in staat opnieuw te bouwen uit dezelfde bron en de uitvoer byte voor byte te vergelijken, zodat een afwijking bewijs wordt in plaats van verdenking.
Zelfs een perfecte overeenkomst bewijst minder dan mensen hopen. Het toont aan dat het artefact overeenkomt met de bron en het buildrecept, niet dat de bron vrij is van fouten en niet dat de gebruikte toolchain betrouwbaar was. Beide zijn het weten waard, maar het zijn verschillende beweringen.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgWaar een symptoom meestal begint
De klacht die deze lezing uitlokt is zelden "de code is gesloten". Meestal is het een concrete observatie: een client die ergens onverwacht naartoe belt, een versie die afwijkt van de release-opmerkingen, of een ondersteuningsproces dat meer vraagt dan de tunnel nodig zou moeten hebben. Elk van die punten wijst op een ander onderdeel.
Onverwacht netwerkverkeer van de client is een vraag over de broncode van de client, en die is te beantwoorden door het codepad te lezen dat de verbinding opent. Een versieverschil is een verpakkingsvraag. Een ondersteuningsproces dat identiteitsdocumenten vraagt is een vraag over het accountsysteem, en geen enkele clientaudit lost die op.
Het onderdeel benoemen maakt van een vaag wantrouwen een concrete controle. Een concrete controle kan worden beantwoord, betwist of gesloten. Het alternatief is een permanent vermoeden zonder volgende stap.
Wat de beoordeling niet kan bereiken, en wat u in plaats daarvan moet doen
Bewaring op de servers van de provider valt buiten het bereik van de client. Dat geldt ook voor het gedrag van een factureringsportaal, een fraudecontroleleverancier of een helpdesk die bijlagen bewaart. Een clientbeoordeling die wordt opgerekt tot "we hebben de dienst geaudit" doet een bewering die het bewijs niet ondersteunt.
Lees wat de operator publiceert over bewaring en verzoeken, noteer de datum, en behandel het als een verklaring van een belanghebbende partij in plaats van een meting. Dat is een zwakkere vorm van bewijs, en expliciet zijn over het verschil is nuttiger dan het in het navertellen op te waarderen.
Gebruik dan wat u hebt als één van meerdere invoer: de identiteit van de geïnstalleerde release, of de software wordt onderhouden, hoe de client is geconfigureerd, en wat de operator over zijn eigen systemen zegt. Open code versterkt die beoordeling op één punt. Het vervangt de rest niet.
Een auditbewering moet altijd haar componenten en versies noemen. Als een rapport niet kan zeggen welke repository en welke build het heeft onderzocht, beschrijft het een bedoeling en geen product.