L’aggiornamento apt fallisce con NO_PUBKEY dopo aver aggiunto un repository VPN

La sorgente apt del vostro fornitore VPN ha rotto il gestore di pacchetti, e la correzione è una decisione, non un comando. NO_PUBKEY, o una lamentela che il repository non ha alcun file Release, significa che apt ha rifiutato di fidarsi di quella sorgente, quindi ogni successiva operazione sui pacchetti continua a stampare lo stesso avviso. Il tunnel in sé è probabilmente innocente. Rispondete a tre domande se volete ancora quella sorgente, e la riparazione corretta segue quasi meccanicamente.

Primo, mettete il guasto nella categoria giusta

Un errore di fiducia nomina il file sorgente e o la chiave mancante o il file Release assente. Un errore di trasporto è diverso: errori di certificato TLS, connessione rifiutata, timeout, o un proxy che rifiuta CONNECT. Questa distinzione decide quale articolo state leggendo, perché una VPN che intercetta TLS o blocca l’host del fornitore produce errori di trasporto, non errori di firma.

Eseguite sudo apt update da solo e leggete la coda, ignorando i risultati in cache sopra. La riga che conta nomina /etc/apt/sources.list.d/ e vi dice quale file aprire.

Se il guasto segue la salita del tunnel, provate con il tunnel abbassato e con il DNS risolto dal resolver di sistema. Una sorgente che funziona senza la VPN è una questione di instradamento o di intercettazione, e nessuna gestione delle chiavi la risolverà.

Tre domande che scelgono il percorso

Installate o aggiornate ancora pacchetti da questa sorgente? Se il client è in uso attivo, riparate la fiducia. Se avete installato il client una volta e ora importate un profilo semplice in NetworkManager, la sorgente è peso morto e la rimozione è la riparazione onesta.

Secondo, il fornitore pubblica una chiave e un’impronta che potete verificare fuori banda? Terzo, chi gestisce le chiavi su questo host: la distribuzione o voi? Una sorgente firmata con una chiave che non potete verificare è un’autorità di aggiornamento che non dovreste concedere.

Rispondere no alla prima domanda chiude l’analisi. Rispondere sì a tutti e tre i punti porta alla riparazione con signed-by, l’unica disposizione che funziona e resta verificabile. Mescolare le due strade, tenendo la sorgente e forzandola, è l’unica opzione che vale la pena escludere esplicitamente.

Perché trusted=yes sembra una correzione e non lo è

La pagina del manuale di sources.list è diretta al riguardo. Impostare l’opzione Trusted su yes dice ad apt di accettare la sorgente anche quando fallisce l’autenticazione, il che disattiva apt-secure per quel repository. La pagina la riserva a un contesto locale, se mai viene usata.

Non è una versione più stretta della fiducia nel fornitore. Rimuove la domanda su chi ha firmato l’indice, quindi chiunque possa rispondere per quel nome host può consegnare alla vostra macchina pacchetti che si installano come root.

Percorso di riparazione: prendete la chiave, poi fissatela

Prendete la chiave dal luogo che il fornitore documenta e disarmatela in un portachiavi gestito dall’amministratore, poi puntate la riga del repository a quel file perché la fiducia non possa derivare.

1. Leggete la riga che fallisce per ottenere l’ID della chiave e il nome del file sorgente.
2. Scaricate la chiave del fornitore corazzata in ASCII ed eseguite gpg --dearmor verso /etc/apt/keyrings/vendor-name.gpg.
3. Aggiungete [signed-by=/etc/apt/keyrings/vendor-name.gpg] alla voce nel file .list di quel fornitore.
4. Eseguite sudo apt update e confermate che la sorgente scarica un indice invece di ripetere l’avviso di firma.

Preferite /usr/share/keyrings per le chiavi che arrivano con un pacchetto e /etc/apt/keyrings per le chiavi che mettete a mano. La separazione non è cosmetica: dice all’amministratore successivo quali chiavi sopravvivranno a un aggiornamento del pacchetto e quali richiedono una persona.

Verificate l’impronta rispetto al valore pubblicato dal fornitore prima di fidarvi. Un ID di chiave incollato da un post del forum è il modo in cui una macchina finisce per fidarsi di un’autorità di aggiornamento che nessuno può nominare.

Percorso di rimozione, e perché l’errore può tornare

Guardate cosa ha scritto realmente l’installatore, perché diversi file possono menzionare lo stesso fornitore e uno di essi è di solito una copia rimasta.

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

apt legge solo i file .list e .sources da quella directory, quindi una copia .save o .distUpgrade è già ignorata; cancellarla comunque impedisce a un lettore successivo di ripristinarla per caso. Rimuovere la sorgente non disinstalla nulla, e apt può poi descrivere il pacchetto VPN installato come installato localmente o non più disponibile, che è un messaggio di stato del pacchetto e non il ritorno dell’errore di fiducia.

Il caso ricorrente è una guida più vecchia che installava chiavi con apt-key nell’anello fidato globale. Quel percorso è deprecato, e un aggiornamento di versione può lasciare la chiave scartata o semplicemente non consultata, ed è esattamente per questo che un errore rimasto silenzioso per un anno compare la settimana in cui aggiornate. Controllate /etc/apt/trusted.gpg.d/, poi spostate la decisione di fiducia nella riga del repository dove appartiene. Se il fornitore stampa ancora istruzioni apt-key, usate signed-by comunque; è la disposizione che il manuale documenta, e quella che sopravvive a un aggiornamento.