Client VPN à code source ouvert : ce que le code prouve et ce qu’il ne peut pas prouver
Un dépôt public est une preuve sur le code source, pas sur le build que vous avez installé ni sur les serveurs qui le sous-tendent. Faites correspondre la version, puis élargissez la revue.
Le code source est publié, la licence est propre, et la connexion ne peut toujours pas être vérifiée de bout en bout. Cet écart est ordinaire et ce n’est pas un scandale. Publier le code rend un composant inspectable par des personnes qu’on n’a pas invitées, ce qui est une propriété réelle et inhabituelle. Il ne s’ensuit pas que le binaire que vous avez installé provienne de ce code, ni que quoi que ce soit exploité par le fournisseur de l’autre côté ait été examiné.
Séparez le composant du produit
Quatre choses peuvent porter l’étiquette open source, et elles sont rarement toutes ouvertes. L’application cliente est celle que les gens visent. L’implémentation du protocole en dessous est un autre artefact, parfois une bibliothèque et parfois du code dans l’arbre. Le logiciel serveur est le troisième, et l’infrastructure propre du fournisseur, le portail de compte et les outils de support sont le quatrième. Chacun peut être ouvert ou fermé indépendamment.
Donc des affirmations comme « notre application est open source » décrivent le premier élément et laissent le reste sans réponse, ce qui n’est pas malhonnête mais plutôt un glissement de catégorie. La question utile est quel dépôt, à quel tag, correspond au composant sur lequel vous comptez.
Cette distinction explique aussi pourquoi deux produits dotés de clients ouverts identiques peuvent offrir des garanties très différentes. Le client est la partie que vous pouvez vérifier ; le comportement de l’opérateur est la partie que vous devez évaluer par d’autres moyens.
Faites correspondre le build installé au tag publié
Un dépôt est un registre d’intentions ; le binaire sur votre disque est ce qui s’exécute. Combler cet écart est un exercice mécanique, et il commence par identifier exactement ce qui est installé, et non ce que la page de téléchargement annonçait.
| 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 |
Les métadonnées du paquet vous donnent la version et l’origine, ce qui écarte le cas trivial d’un paquet périmé ou substitué. Elles ne vous disent pas comment ce paquet a été compilé, et c’est précisément la question à laquelle les builds reproductibles existent pour répondre. Builds reproductibles permettent à un tiers indépendant de reconstruire depuis la même source et de comparer la sortie octet par octet, de sorte qu’une divergence devient une preuve plutôt qu’un soupçon.
Même une correspondance parfaite prouve moins que ce que les gens espèrent. Elle montre que l’artefact correspond à la source et à la recette de build, non que la source soit exempte de défauts, ni que la chaîne d’outils utilisée ait été digne de confiance. Les deux méritent d’être connus, mais ce sont des affirmations différentes.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgOù un symptôme commence le plus souvent
La plainte qui motive cette lecture est rarement « le code est fermé ». C’est généralement une observation précise : un client qui appelle un endroit inattendu, une version différente des notes de version, ou un processus de support qui demande plus que ce dont le tunnel devrait avoir besoin. Chacun de ces points désigne un composant différent.
Le trafic réseau inattendu du client est une question de code source du client, et on peut y répondre en lisant le chemin de code qui ouvre la connexion. Un écart de version est une question de packaging. Un processus de support qui demande des pièces d’identité est une question de système de comptes, et aucune audit du client ne le résoudra.
Nommer le composant transforme une méfiance vague en vérification précise. Une vérification précise peut recevoir une réponse, être discutée ou être close. L’alternative est une suspicion permanente sans étape suivante.
Ce que la revue ne peut pas atteindre, et que faire à la place
La conservation sur les serveurs du fournisseur échappe au client. Tout comme le comportement d’un portail de facturation, d’un prestataire de contrôle de fraude ou d’un service de support qui conserve les pièces jointes. Une revue du client étirée jusqu’à « nous avons audité le service » avance une affirmation que les preuves ne soutiennent pas.
Lisez ce que l’opérateur publie sur la conservation et les demandes, notez la date, et traitez-le comme une déclaration d’une partie intéressée plutôt qu’une mesure. C’est une forme plus faible de preuve, et être explicite sur la différence est plus utile que de la rehausser en la racontant.
Utilisez ensuite ce que vous avez comme une entrée parmi plusieurs : l’identité de la version installée, si le logiciel est maintenu, la configuration du client, et ce que l’opérateur dit de ses propres systèmes. Le code ouvert renforce cette évaluation sur un point. Il ne remplace pas le reste.
Une affirmation d’audit devrait toujours nommer ses composants et ses versions. Si un rapport ne peut pas dire quel dépôt et quel build il a examinés, il décrit une intention plutôt qu’un produit.