Compilations reproductibles pour les applications VPN : ce qu'une correspondance prouve
Une recompilation concordante relie un binaire distribué au code source et aux outils déclarés. Elle ne dit rien du service VPN derrière ce binaire ni de ses journaux.
La reproductibilité est une propriété de la chaîne d'approvisionnement : les mêmes entrées déclarées doivent produire le même artefact. Pour un client VPN, cette affirmation lie l'installateur que vous avez téléchargé au code source et à la chaîne d'outils que quiconque peut reconstruire. Elle ne dit rien du service auquel le client se connecte.
La question utile est donc étroite et a une réponse. Le projet publie-t-il une procédure, et votre artefact précis y correspond-il ?
Où une compilation cesse d'être déterministe
Les compilateurs intègrent des horodatages, des chemins absolus et des noms d'hôtes de compilation, sauf si on le leur interdit. Les archives enregistrent l'ordre des fichiers et les dates de modification, les éditeurs de liens font varier leur sortie selon la version de la chaîne d'outils, et la compression parallèle peut réordonner des blocs. N'importe lequel de ces éléments fait différer en octets deux compilations d'un même code source sans qu'il se passe rien de sinistre. Le déterminisme s'incorpore à une compilation par conception, il ne s'hérite jamais par défaut.
Un projet qui revendique la reproductibilité doit nommer la normalisation qu'il applique : horodatages fixes, chemins remappés, entrées d'archive triées, versions épinglées du compilateur et des dépendances. Sans cette liste, un écart ne peut pas être interprété, car l'espace des variations légitimes n'est pas défini.
Les entrées déclarées doivent aussi être complètes. Une URL de dépôt sans étiquette n'est pas une révision, un fichier de verrouillage sans empreinte n'est pas un ensemble de dépendances, et un script de compilation qui télécharge un outil à l'exécution a une entrée que personne ne peut épingler. Chaque lacune devient plus tard une différence. Complétez la liste avant de comparer quoi que ce soit, car une liste incomplète ne peut pas échouer d'une manière qui ait un sens.
| Input | How it drifts | What pins it |
|---|---|---|
| Source | Branch moves after release | Commit hash in the build metadata |
| Toolchain | Compiler patch level differs | Container image digest |
| Packaging | Archive order and mtimes vary | Normalised archive settings |
Ce que la comparaison vérifie réellement
Une partie indépendante recompile dans l'environnement déclaré et compare la sortie à l'artefact publié. L'identité bit à bit est la forme forte ; une étape de normalisation documentée, où une différence consignée est inversée puis les résultats concordent, est la forme plus faible mais toujours utile.
La comparaison porte sur le binaire. Une signature répond à une autre question : elle associe une version à une clé et une clé à une identité, et un projet peut avoir des signatures valides sur des artefacts que personne n'a recompilés. Les deux contrôles se cumulent au lieu de se remplacer.
sha256sum wireguard-installer.msi gpg --verify wireguard-installer.msi.sig wireguard-installer.msi
Exécutez les deux avant d'installer, et comparez l'empreinte à celle publiée pour la même version et la même plateforme. Une empreinte qui correspond à la page de l'éditeur prouve que le téléchargement est arrivé intact ; un binaire recompilé qui correspond à l'empreinte publiée par l'éditeur prouve quelque chose de plus fort sur la manière dont il a été fabriqué.
Pourquoi un écart n'est pas une preuve de manipulation
La plupart des écarts viennent d'une entrée que personne n'a maîtrisée. Une autre version de correctif du compilateur, un chemin de compilation qui a fuité dans les symboles de débogage, une locale qui a changé l'ordre de tri ou une étape d'empaquetage appliquée après la comparaison produisent tous une empreinte différente de celle d'un travail honnête.
C'est pourquoi un écart doit être lu à la lumière de la procédure documentée avant de devenir une histoire. Si la procédure épingle tout et que la différence reste inexpliquée, c'est une constatation réelle qui mérite d'être signalée au projet. Si la procédure est muette sur l'empaquetage, la différence peut être tout à fait attendue.
La symétrie compte aussi ici : une correspondance ne prouve pas que le code source est exempt de défauts, seulement que le binaire y correspond. Un code bien audité et un code reproductible sont des propriétés différentes, et un projet peut avoir l'une sans l'autre.
Ce que l'affirmation dit du service derrière l'application
Le client est un programme sur votre appareil ; le service est constitué de serveurs, de systèmes de comptes et de politiques de conservation ailleurs. La reproductibilité contraint le premier et ne dit rien du second, quelle que soit la rigueur avec laquelle l'installateur est vérifié.
La configuration du point de terminaison peut aussi changer après l'installation, via des paramètres distants ou un profil contrôlé par le fournisseur. Ces changements arrivent par le réseau et ne sont couverts par aucune empreinte calculée avant la connexion.
Lisez l'affirmation dans sa portée réelle, puis vérifiez séparément la question voisine : ce que le fournisseur enregistre, et sous quelle juridiction il répond aux demandes. Un binaire vérifié et un service non vérifié peuvent coexister, et c'est exactement le cas qu'un contrôle de chaîne d'approvisionnement est conçu pour rendre visible, non pour corriger.