La mise à jour apt échoue avec NO_PUBKEY après l’ajout d’un dépôt VPN

La source apt de votre fournisseur VPN a cassé votre gestionnaire de paquets, et le correctif est une décision, pas une commande. NO_PUBKEY, ou une plainte indiquant que le dépôt n’a pas de fichier Release, signifie qu’apt a refusé de faire confiance à cette source, si bien que chaque opération de paquets ultérieure continue d’imprimer le même avertissement. Le tunnel lui-même est probablement innocent. Répondez à trois questions sur le point de savoir si vous voulez encore cette source, et la réparation correcte suit presque mécaniquement.

D’abord, rangez la panne dans la bonne catégorie

Un échec de confiance nomme le fichier source et soit la clé manquante, soit le fichier Release absent. Un échec de transport est différent : erreurs de certificat TLS, connexion refusée, délais d’attente dépassés, ou un proxy qui refuse CONNECT. Cette distinction décide quel article vous lisez, car un VPN qui intercepte TLS ou bloque l’hôte de l’éditeur produit des erreurs de transport, pas des erreurs de signature.

Lancez sudo apt update seul et lisez la fin, en ignorant les résultats mis en cache au-dessus. La ligne qui compte nomme /etc/apt/sources.list.d/ et vous dit quel fichier ouvrir.

Si la panne suit la montée du tunnel, testez avec le tunnel arrêté et avec le DNS résolu par le résolveur du système. Une source qui fonctionne sans le VPN est une question de routage ou d’interception, et aucune gestion de clés n’y remédiera.

Trois questions qui choisissent la voie

Installez-vous ou mettez-vous encore à jour des paquets depuis cette source ? Si le client est réellement utilisé, réparez la confiance. Si vous avez installé le client une fois et importez maintenant un profil simple dans NetworkManager, la source est un poids mort et la suppression est la réparation honnête.

Deuxièmement, l’éditeur publie-t-il une clé et une empreinte que vous pouvez vérifier hors canal ? Troisièmement, qui gère les clés sur cet hôte : la distribution ou vous ? Une source signée par une clé que vous ne pouvez pas vérifier est une autorité de mise à jour que vous ne devriez pas accorder.

Répondre non à la première question termine l’analyse. Répondre oui aux trois points mène à la réparation par signed-by, le seul dispositif qui fonctionne et reste auditable. Mélanger les deux voies, en gardant la source et en la forçant, est la seule option qui vaut la peine d’être écartée explicitement.

Pourquoi trusted=yes ressemble à un correctif sans en être un

La page du manuel de sources.list est explicite à ce sujet. Régler l’option Trusted sur yes dit à apt d’accepter la source même lorsqu’elle échoue à l’authentification, ce qui désactive apt-secure pour ce dépôt. La page la réserve à un contexte local, si tant est qu’elle soit utilisée.

Ce n’est pas une version plus étroite de la confiance envers l’éditeur. Cela supprime la question de savoir qui a signé l’index, de sorte que quiconque peut répondre de ce nom d’hôte peut fournir à votre machine des paquets qui s’installent en root.

Voie de réparation : récupérez la clé, puis épinglez-la

Récupérez la clé à l’endroit que l’éditeur documente et désarmez-la dans un trousseau géré par l’administrateur, puis pointez la ligne du dépôt vers ce fichier pour que la confiance ne puisse pas dériver.

1. Lisez la ligne qui échoue pour obtenir l’ID de la clé et le nom du fichier source.
2. Téléchargez la clé blindée ASCII de l’éditeur et exécutez gpg --dearmor vers /etc/apt/keyrings/vendor-name.gpg.
3. Ajoutez [signed-by=/etc/apt/keyrings/vendor-name.gpg] à l’entrée du fichier .list de cet éditeur.
4. Exécutez sudo apt update et confirmez que la source récupère un index au lieu de répéter l’avertissement de signature.

Préférez /usr/share/keyrings pour les clés qui arrivent avec un paquet et /etc/apt/keyrings pour les clés que vous placez à la main. La séparation n’est pas cosmétique : elle indique à l’administrateur suivant quelles clés survivront à une mise à jour de paquet et lesquelles ont besoin d’un humain.

Vérifiez l’empreinte par rapport à la valeur publiée par l’éditeur avant de lui faire confiance. Un ID de clé collé depuis un message de forum est la façon dont une machine finit par faire confiance à une autorité de mise à jour que personne ne peut nommer.

Voie de suppression, et pourquoi l’erreur peut revenir

Regardez ce que l’installateur a réellement écrit, car plusieurs fichiers peuvent mentionner le même éditeur et l’un d’eux est généralement une copie résiduelle.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt ne lit que les fichiers .list et .sources de ce répertoire, donc une copie .save ou .distUpgrade est déjà ignorée ; la supprimer quand même empêche un lecteur ultérieur de la restaurer par accident. Supprimer la source ne désinstalle rien, et apt peut alors décrire le paquet VPN installé comme installé localement ou comme n’étant plus disponible, ce qui est un message d’état de paquet et non le retour de l’erreur de confiance.

Le cas récurrent est une consigne plus ancienne qui installait des clés avec apt-key dans le trousseau de confiance global. Cette voie est obsolète, et une mise à niveau de version peut laisser la clé écartée ou simplement non consultée, et c’est exactement pourquoi une erreur restée silencieuse pendant un an apparaît la semaine où vous mettez à niveau. Vérifiez /etc/apt/trusted.gpg.d/, puis déplacez la décision de confiance dans la ligne du dépôt, là où elle appartient. Si l’éditeur imprime encore des instructions apt-key, utilisez signed-by quand même ; c’est le dispositif que le manuel documente, et celui qui survit à une mise à niveau.