Open-Source-VPN-Client: Was der Code beweist und was nicht
Ein öffentliches Repository ist ein Beleg über Quellcode, nicht über den von Ihnen installierten Build oder die Server dahinter. Gleichen Sie das Release ab und weiten Sie dann die Prüfung aus.
Der Quellcode ist veröffentlicht, die Lizenz ist sauber, und die Verbindung lässt sich trotzdem nicht durchgängig überprüfen. Diese Lücke ist normal und kein Skandal. Code zu veröffentlichen macht eine Komponente für Menschen prüfbar, die nicht eingeladen wurden, und das ist eine echte und ungewöhnliche Eigenschaft. Daraus folgt nicht, dass die installierte Binärdatei aus diesem Code stammt, oder dass irgendetwas, was der Anbieter auf der anderen Seite betreibt, überhaupt geprüft wurde.
Trennen Sie die Komponente vom Produkt
Vier Dinge können das Open-Source-Etikett tragen, und selten sind alle offen. Die Client-Anwendung ist das, was die Leute meinen. Die Protokollimplementierung darunter ist ein anderes Artefakt, manchmal eine Bibliothek und manchmal Code im Baum. Die Serversoftware ist ein drittes, und die eigene Infrastruktur des Anbieters, das Kundenportal und die Support-Werkzeuge sind ein viertes. Jedes kann unabhängig offen oder geschlossen sein.
Aussagen wie "unsere App ist Open Source" beschreiben daher den ersten Punkt und lassen den Rest unbeantwortet, was weniger Unehrlichkeit als ein Kategorienfehler ist. Die nützliche Frage lautet, welches Repository in welchem Tag der Komponente entspricht, auf die Sie sich verlassen.
Dieser Unterschied erklärt auch, warum zwei Produkte mit identischen offenen Clients sehr unterschiedliche Zusicherungen bieten können. Der Client ist der Teil, den Sie prüfen können; das Verhalten des Betreibers ist der Teil, den Sie mit anderen Mitteln bewerten müssen.
Gleichen Sie den installierten Build mit dem veröffentlichten Tag ab
Ein Repository ist eine Aufzeichnung der Absicht; die Binärdatei auf Ihrer Festplatte ist das, was läuft. Diese Lücke zu schließen ist eine mechanische Übung, und sie beginnt damit, genau festzustellen, was installiert ist, und nicht, was die Download-Seite angekündigt hat.
| 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 |
Paketmetadaten nennen Ihnen Version und Herkunft, was den trivialen Fall eines veralteten oder ersetzten Pakets ausschließt. Sie sagen Ihnen nicht, wie das Paket kompiliert wurde, und genau diese Frage sollen reproduzierbare Builds beantworten. Reproduzierbare Builds erlauben es einer unabhängigen Partei, aus derselben Quelle neu zu bauen und die Ausgabe Byte für Byte zu vergleichen, sodass eine Abweichung zum Beleg statt zum Verdacht wird.
Selbst eine perfekte Übereinstimmung beweist weniger, als Menschen hoffen. Sie zeigt, dass das Artefakt zur Quelle und zum Build-Rezept passt, nicht dass die Quelle fehlerfrei ist und nicht dass die verwendete Toolchain vertrauenswürdig war. Beides bleibt wissenswert, aber es sind verschiedene Aussagen.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgWo ein Symptom meist beginnt
Die Beschwerde, die diese Lektüre auslöst, lautet selten "der Code ist geschlossen". Meist ist es eine konkrete Beobachtung: ein Client, der irgendwo unerwartet anruft, eine Version, die von den Release-Notes abweicht, oder ein Support-Prozess, der mehr verlangt, als der Tunnel brauchen sollte. Jeder dieser Punkte zeigt auf eine andere Komponente.
Unerwarteter Netzwerkverkehr des Clients ist eine Frage des Client-Quellcodes und lässt sich durch Lesen des Codepfads beantworten, der die Verbindung öffnet. Eine Versionsabweichung ist eine Frage der Paketierung. Ein Support-Prozess, der Ausweisdokumente verlangt, ist eine Frage des Kontosystems, und keine noch so gründliche Client-Prüfung wird sie lösen.
Die Komponente zu benennen verwandelt vages Misstrauen in eine konkrete Prüfung. Eine konkrete Prüfung lässt sich beantworten, bestreiten oder abschließen. Die Alternative ist ein dauerhafter Verdacht ohne nächsten Schritt.
Was die Prüfung nicht erreicht und was stattdessen zu tun ist
Die Aufbewahrung auf den Servern des Anbieters liegt außerhalb der Reichweite des Clients. Ebenso das Verhalten eines Abrechnungsportals, eines Betrugsprüfungsdienstleisters oder eines Support-Desks, der Anhänge aufbewahrt. Eine Client-Prüfung, die zu "wir haben den Dienst auditiert" ausgeweitet wird, erhebt eine Behauptung, die die Belege nicht stützen.
Lesen Sie, was der Betreiber zur Aufbewahrung und zu Anfragen veröffentlicht, notieren Sie das Datum und behandeln Sie es als Aussage einer interessierten Partei statt als Messung. Das ist eine schwächere Form des Belegs, und die Differenz ausdrücklich zu benennen ist nützlicher, als sie beim Nacherzählen aufzuwerten.
Nutzen Sie dann das, was Sie haben, als einen von mehreren Eingaben: die Identität des installierten Releases, ob die Software gepflegt wird, wie der Client konfiguriert ist und was der Betreiber über seine eigenen Systeme sagt. Offener Code stärkt diese Bewertung an einer Stelle. Er ersetzt den Rest nicht.
Eine Audit-Behauptung sollte immer ihre Komponenten und Versionen nennen. Wenn ein Bericht nicht sagen kann, welches Repository und welchen Build er untersucht hat, beschreibt er eine Absicht statt ein Produkt.