HTTPS et un VPN n’authentifient pas le paquet que vous installez

Une mise à jour échoue, et la suggestion du fil suit une ligne connue : le trafic passe par un VPN, donc le téléchargement doit être digne de confiance, et la vérification de signature est assouplie pour contourner l’erreur. Deux idées distinctes ont été fusionnées en une seule phrase. Le chiffrement protège un chemin entre extrémités ; l’authentification décide si les octets venaient de l’éditeur que vous visiez. Un tunnel fournit la première et ne dit rien de la seconde.

Le symptôme est généralement une erreur de vérification sur un seul hôte, dans un seul dépôt, alors que tout le reste se met à jour normalement. Cette forme dit déjà que le chemin réseau fonctionne et que le désaccord porte sur la confiance.

Deux contrôles qui répondent à des questions différentes

La sécurité du transport répond qui se trouve à l’autre bout de cette connexion et si quelqu’un sur le chemin peut la lire ou la modifier. L’authentification du paquet répond si cet artefact a été publié par l’autorité que vous avez configurée, et elle doit survivre à un téléchargement via un miroir que vous ne contrôlez pas.

Ces questions ne se recoupent qu’aux bords. Un certificat correct sur un miroir prouve que le miroir est le miroir ; il ne prouve pas que le miroir contient un contenu d’éditeur non modifié. Un paquet signé prouve que l’éditeur l’a signé ; il ne vous dit pas que le réseau a livré la version la plus récente ni que le dépôt que vous avez indiqué est celui que votre organisation a approuvé.

Le mode de défaillance que les gens créent en désactivant des contrôles est une perte permanente de la seconde garantie, en échange d’un téléchargement réussi. Cet échange est invisible jusqu’au jour où il compte.

Ce qu’apt authentifie réellement

Le modèle d’APT est une chaîne d’archive authentifiée. Les métadonnées de publication signées mènent par somme de contrôle aux index de paquets, et ces index mènent par somme de contrôle aux fichiers de paquet individuels. C’est la vérification de la chaîne qui rend un miroir non fiable mais utilisable : le miroir peut servir ce qu’il veut, et la signature des métadonnées décide si APT l’accepte.

Ce n’est délibérément pas la même chose que vérifier une signature de mainteneur sur chaque paquet installé, et la distinction explique pourquoi « le paquet est signé » et « l’archive est authentifiée » sont employés indifféremment dans les rapports de bogue alors qu’ils veulent dire des choses différentes.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

Lisez la sortie de la mise à jour, pas seulement le code de sortie. APT nomme le dépôt dont les métadonnées ont échoué, et ce nom est la frontière à examiner. Un dépôt marqué comme fiable sans vérification de signature, ou une dérogation pour un dépôt non sécurisé, est une décision de configuration que quelqu’un a prise et devrait pouvoir expliquer.

La fraîcheur est encore une propriété distincte. Un fichier de métadonnées signé valablement peut être plus ancien que celui que vous avez vu la semaine dernière, c’est pourquoi les métadonnées de publication portent une date d’expiration et pourquoi un problème d’horloge sur le client peut produire des erreurs de vérification qui ressemblent à des problèmes de clé.

Ce que dnf5 vérifie séparément

Le côté RPM expose deux commutateurs distincts, et les confondre produit la même classe d’erreur dans l’autre sens. L’un contrôle si les fichiers de paquet doivent porter une signature valide ; l’autre contrôle si les métadonnées de dépôt doivent être signées. Ils peuvent être réglés indépendamment, et un système peut être strict sur l’un et permissif sur l’autre.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

La requête de paquet montre à quoi ressemblent les métadonnées de signature de la copie installée, ce qui est un contrôle de réalité utile face à un fichier de configuration qui revendique la rigueur. Ce qu’elle ne vous dit pas, c’est la politique prise en charge de la distribution, et c’est elle que vous devriez suivre plutôt qu’une instruction générique « activez GPG » trouvée sur un forum.

Là où les deux gestionnaires diffèrent, la différence est architecturale et non le signe que l’un serait plus faible. Les deux authentifient le contenu de l’éditeur ; ils placent la signature à des points différents de la chaîne.

Ce que le tunnel ajoute et ce qu’il n’ajoute pas

Un VPN peut fournir une route nécessaire, garder le trafic de mise à jour hors d’un réseau d’accès non fiable et réduire ce qu’un observateur local voit. Ce sont de vrais avantages opérationnels, et aucun d’eux n’est l’authentification de l’éditeur.

HTTPS ajoute sa propre garantie, et elle est plus étroite qu’il n’y paraît. Il authentifie l’extrémité TLS à laquelle vous vous êtes connecté. Si cette extrémité est un miroir, vous avez authentifié le miroir, pas le contenu d’archive qu’il sert. C’est précisément le cas que la chaîne de métadonnées signées existe pour traiter.

Aucun des deux contrôles ne promet la disponibilité. Un réseau peut refuser la livraison, et un objet authentifié n’est pas automatiquement le plus récent. Utilisez la politique de fraîcheur du gestionnaire de paquets lui-même au lieu de la déduire de la présence d’une icône de cadenas.

Diagnostiquez la frontière qui a échoué

Nommez l’étape avant de changer quoi que ce soit : résolution DNS, le proxy ou la route, l’identité de l’extrémité TLS, l’authentification de l’archive, les vérifications de signature de paquet ou l’installation. Chacune a une forme d’erreur et un propriétaire distincts.

Réparer un chemin réseau ne devrait jamais impliquer de déclarer fiable une clé de signature inconnue, d’ignorer des certificats ou d’accepter une configuration de dépôt que vous n’avez pas demandée. Si une clé a réellement tourné, la distribution ou le propriétaire du dépôt publie la nouvelle clé par un canal que vous pouvez vérifier, et c’est la correction à appliquer.

Notez quelle frontière a échoué et qui en est responsable. La prochaine panne de mise à jour sera à une autre frontière, et avoir la liste en fait un diagnostic de cinq minutes au lieu d’une nouvelle discussion sur le point de savoir si le tunnel rend les mises à jour sûres.