L’actualització amb apt falla amb NO_PUBKEY després d’afegir un repositori VPN

La font apt del vostre proveïdor VPN ha espatllat el gestor de paquets, i la solució és una decisió, no una ordre. NO_PUBKEY, o una queixa que el repositori no té cap fitxer Release, vol dir que apt s’ha negat a confiar en aquesta font, així que cada operació de paquets posterior continua imprimint el mateix avís. El túnel mateix probablement és innocent. Responeu tres preguntes sobre si encara voleu aquesta font, i la reparació correcta arriba gairebé mecànicament.

Primer, poseu la fallada a la categoria correcta

Una fallada de confiança anomena el fitxer de la font i o bé la clau que falta o bé el fitxer Release absent. Una fallada de transport es veu diferent: errors de certificat TLS, connexió refusada, temps d’espera superats o un proxy que refusa CONNECT. Aquesta distinció decideix quin article llegiu, perquè un VPN que intercepta TLS o bloqueja l’amfitrió del proveïdor produeix errors de transport, no errors de signatura.

Executeu sudo apt update tot sol i llegiu la cua, ignorant les entrades a la memòria cau de més amunt. La línia que importa anomena /etc/apt/sources.list.d/ i us diu quin fitxer cal obrir.

Si la fallada segueix l’aixecament del túnel, proveu amb el túnel aturat i amb el DNS resolt pel resolutor del sistema. Una font que funciona sense el VPN és una qüestió d’encaminament o d’intercepció, i cap quantitat de gestió de claus ho arreglarà.

Tres preguntes que trien el camí

Encara instal·leu o actualitzeu paquets des d’aquesta font? Si el client s’usa activament, repareu la confiança. Si vau instal·lar el client una vegada i ara importeu un perfil senzill a NetworkManager, la font és pes mort i eliminar-la és la reparació honesta.

Segon, el proveïdor publica una clau i una empremta que pugueu verificar fora de banda? Tercer, qui gestiona les claus en aquest amfitrió: la distribució o vosaltres? Una font signada per una clau que no podeu verificar és una autoritat d’actualització que no hauríeu de concedir.

Respondre no a la primera pregunta acaba l’anàlisi. Respondre sí a les tres apunta a la reparació amb signed-by, l’única disposició que alhora funciona i es manté auditable. Barrejar els dos camins, mantenint la font i forçant-la, és l’única opció que val la pena descartar explícitament.

Per què trusted=yes sembla una solució i no ho és

La pàgina del manual de sources.list és directa sobre això. Establir l’opció Trusted a yes diu a apt que accepti la font fins i tot quan falla l’autenticació, cosa que desactiva apt-secure per a aquell repositori. La pàgina la reserva per a un context local, si és que s’usa.

Això no és una versió més estreta de confiar en el proveïdor. Elimina la pregunta de qui ha signat l’índex, així que qualsevol que pugui respondre per aquell nom d’amfitrió pot lliurar a la vostra màquina paquets que s’instal·len com a root.

Camí de reparació: obteniu la clau i fixeu-la

Obteniu la clau del lloc que el proveïdor documenta i desempaqueteu-la en un anell de claus gestionat per l’administrador, després apunteu la línia del repositori a aquest fitxer perquè la confiança no pugui derivar.

1. Llegiu la línia que falla per obtenir l’ID de la clau i el nom del fitxer de la font.
2. Baixeu la clau del proveïdor blindada en ASCII i executeu gpg --dearmor cap a /etc/apt/keyrings/vendor-name.gpg.
3. Afegiu [signed-by=/etc/apt/keyrings/vendor-name.gpg] a l’entrada del fitxer .list d’aquell proveïdor.
4. Executeu sudo apt update i confirmeu que la font baixa un índex en lloc de repetir l’avís de signatura.

Preferiu /usr/share/keyrings per a les claus que arriben amb un paquet i /etc/apt/keyrings per a les claus que hi poseu a mà. La divisió no és cosmètica: diu al següent administrador quines claus sobreviuran a una actualització de paquet i quines necessiten una persona.

Verifiqueu l’empremta amb el valor publicat pel proveïdor abans de confiar-hi. Un ID de clau enganxat d’un missatge de fòrum és com una màquina acaba confiant en una autoritat d’actualització que ningú no pot anomenar.

Camí d’eliminació, i per què l’error pot tornar

Mireu què va escriure realment l’instal·lador, perquè diversos fitxers poden esmentar el mateix proveïdor i un d’ells sol ser una còpia sobrera.

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

apt només llegeix fitxers .list i .sources d’aquell directori, així que una còpia .save o .distUpgrade ja s’ignora; esborrar-la igualment evita que un lector posterior la restauri per accident. Eliminar la font no desinstal·la res, i apt pot descriure llavors el paquet VPN instal·lat com a instal·lat localment o ja no disponible, que és un missatge d’estat del paquet i no el retorn de l’error de confiança.

El cas recurrent són instruccions antigues que instal·laven claus amb apt-key a l’anell de confiança global. Aquest camí està obsolet, i una actualització de versió pot deixar la clau caiguda o simplement no consultada, que és exactament per què un error que va estar callat un any apareix la setmana que actualitzeu. Reviseu /etc/apt/trusted.gpg.d/, i després moveu la decisió de confiança a la línia del repositori on pertoca. Si el proveïdor encara imprimeix instruccions d’apt-key, feu servir signed-by igualment; és la disposició que documenta el manual i la que sobreviu a una actualització.