Source APT VPN : ce qu’elle accorde et comment la limiter

Télécharger un client VPN est une décision unique ; ajouter son dépôt APT ne l’est pas. Le second indique au gestionnaire de paquets d’où pourra venir un logiciel futur, et c’est un transfert permanent d’autorité plutôt qu’un téléchargement. Cela peut être le bon arrangement quand l’éditeur tient correctement un dépôt. Il mérite tout de même une décision réfléchie, et la plupart des guides d’installation l’omettent.

Une signature authentifie une archive, pas son code

APT vérifie les métadonnées signées du dépôt, puis fait confiance aux sommes de contrôle qu’elles contiennent pour les paquets qu’il récupère. Cela prouve que l’archive correspond à ce que le détenteur de la clé a publié, et rien sur le code qu’elle contient. Un paquet correctement signé peut encore porter des scripts de maintenance dangereux, et ces scripts s’exécutent en root pendant l’installation du paquet. Le manuel apt-secure trace exactement cette frontière entre l’authentification de l’archive et un examen du logiciel.

La question utile n’est donc pas de savoir si la signature est valide, car une signature cassée arrête de toute façon l’installation. Elle est de savoir à quelle signature vous choisissez de faire confiance désormais. Une clé de signature volée est pire qu’un paquet volé, car l’attaquant continue de produire des métadonnées valides longtemps après la première mauvaise publication. La rotation est la seule réparation, et elle dépend de la publication par l’éditeur d’une nouvelle clé via un canal que vous pouvez vérifier indépendamment.

C’est pourquoi l’identité de la clé mérite autant d’attention que l’URL du dépôt. Une clé prise à une adresse dans une vieille réponse de forum n’établit rien sur l’éditeur, tandis que HTTPS protège le transport vers celui qui a répondu au téléphone. La sécurité du transport et l’identité de l’éditeur sont des questions distinctes, et seule la première se règle avec un certificat.

Limitez la clé à la source, pas au système

L’APT moderne accepte une référence Signed-By propre à la source. Une clé gérée par l’exploitant peut résider sous /etc/apt/keyrings/, et l’entrée de source nomme la clé autorisée à authentifier cette archive. C’est plus étroit que de jeter la même clé dans un ensemble de confiance global, où elle peut se porter garante de sources que vous n’avez jamais voulu autoriser. Suivez la version d’APT installée et les instructions actuelles de l’éditeur au lieu de mélanger des fragments de générations différentes de guides.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

Ne réparez jamais un échec de signature en désactivant la vérification ou en marquant une archive inconnue comme digne de confiance. Cela échange une erreur visible contre une invisible, et l’invisible dure jusqu’à ce que quelqu’un audite la liste des sources. Si la clé ne correspond pas, la correcte solution est de trouver la bonne clé, pas de retirer le contrôle.

Obtenez les détails du dépôt et l’identité de la clé auprès du projet ou d’un administrateur géré. Une clé copiée d’un billet de blog est une affirmation sur la paternité, pas une preuve. Quand un éditeur publie un canal de rotation, notez-le en même temps que la clé, car ce canal est ce qui rend la rotation suivante possible.

L’épinglage de source n’est pas une liste blanche de paquets

Restreindre une clé à une source limite l’archive qu’elle peut authentifier, pas les paquets que cette archive peut publier. Le dépôt peut livrer bien plus que le client VPN que vous vouliez, et la sélection des candidats et les priorités d’APT décident quelle version éligible l’emporte. Examinez la transaction proposée avant de la confirmer, y compris la liste des dépendances, car les dépendances viennent de la même archive. La portée d’une clé ne peut pas exprimer ’ce paquet seulement’.

Si vous avez besoin d’un contrôle plus fort, exprimez-le comme une politique sur les noms ou les versions de paquets et maintenez cette politique sous gestion de configuration. Lire une transaction prend une minute ; découvrir un paquet inattendu six mois plus tard prend une revue.

Les paquets inattendus sont le moment de s’arrêter plutôt que de continuer, et la question pour le propriétaire de l’archive est pourquoi ils sont nécessaires. Un dépôt qui publie une douzaine de paquets autour d’un client est normal pour un éditeur qui livre une suite de bureau. C’est aussi une surface plus large que ne le laissait entendre le guide d’installation, et c’est la partie qui vaut la peine d’être notée. Aucun des deux résultats n’est une raison de se méfier de la signature ; les deux sont des raisons d’écrire ce que vous avez accepté.

Consignez l’autorité et comment la retirer

Notez le propriétaire de l’archive, la version du système d’exploitation prise en charge, le canal de rotation de la clé et la procédure de retrait. Ces quatre faits sont ce dont un successeur a besoin quand le client est retiré ou que l’éditeur fait tourner sa clé. Sans eux, la personne suivante hérite d’une ligne de sources et d’un fichier de clé sans aucune histoire.

Le retrait est l’étape que l’on saute, alors rédigez-la au moment de l’installation. Supprimez l’entrée de source et sa clé dédiée ensemble, et vérifiez si cette clé est référencée ailleurs avant de supprimer le fichier. Une clé partagée supprimée sans ce contrôle transforme un nettoyage en panne sans rapport, ce qui est le pire résultat pour un changement de routine. Confirmez ensuite que les mises à jour ordinaires se résolvent encore une fois l’entrée disparue.

Une chose subsiste après le retrait du dépôt : tout paquet déjà installé depuis celui-ci continue de fonctionner jusqu’à ce que quelque chose le remplace. La question honnête est quelle autorité vous avez ajoutée, et avec quelle étroitesse son rôle a été exprimé.