Debian 11 e Kali Linux: come risolvere l'avviso apt-key deprecato

L’avviso apt-key deprecato non è un difetto cosmetico: indica che la gestione delle chiavi APT va spostata da un meccanismo globale e vecchio a un modello più pulito, con chiavi separate per repository. Su Debian 11 e su Kali Linux il problema compare spesso dopo l’aggiunta di repository di terze parti, o quando si aggiornano sistemi che hanno ancora istruzioni storiche basate su apt-key add.

Il punto non è solo “togliere l’avviso”. Il punto è evitare che una chiave fidata per un repository venga trattata come fidata per tutto il sistema. La correzione giusta consiste nel salvare la chiave in un file .gpg o .asc dedicato e nel collegarla al repository con l’opzione signed-by=. In pratica, ogni fonte APT deve avere la sua chiave, il suo file e il suo riferimento esplicito.

Perché apt-key è un problema su Debian 11 e Kali

apt-key inseriva la chiave nel portachiavi globale di APT. Questo funzionava, ma rendeva impossibile limitare la fiducia a un solo repository. Se una chiave finiva nel trust store globale, APT poteva usarla per firmare qualunque origine configurata. Per ambienti con più repository, o con software esterno, è un rischio inutile.

Debian 11 e Kali Linux non bloccano per forza il funzionamento subito, ma mostrano l’avviso perché il metodo è in dismissione. In più, molte guide vecchie installano chiavi in /etc/apt/trusted.gpg o in /etc/apt/trusted.gpg.d/ senza associare il repository a una chiave specifica. È comodo all’inizio, poi diventa difficile fare audit, rimuovere un vendor, o capire quale chiave sta autorizzando quale pacchetto.

Che cosa cambia davvero nel modello corretto

Il modello attuale è semplice: la chiave del repository va in un file dedicato, e la riga del repository in /etc/apt/sources.list oppure in /etc/apt/sources.list.d/*.list deve dichiarare signed-by=/percorso/della/chiave. Così APT usa quella chiave solo per quel repository. Se domani rimuovi il software, cancelli anche il file della chiave e chiudi il cerchio.

La regola pratica è questa: niente più apt-key add, niente più fiducia globale, niente più chiavi sparse senza contesto. Se trovi una guida che ti chiede di eseguire apt-key adv --keyserver, considera quella procedura superata, a meno di casi molto particolari e comunque temporanei.

Come capire se il sistema è ancora configurato male

Il primo controllo è vedere se il warning compare durante un aggiornamento. Su Debian 11 o Kali, esegui:

sudo apt update

Se la configurazione è vecchia, potresti vedere messaggi simili a:

W: https://example.repo/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Per capire quali chiavi sono ancora nel trust store globale, usa:

sudo apt-key list

Il comando funziona ancora in molti casi, ma serve solo come diagnosi. Non è il metodo da usare per una nuova configurazione. Se vedi chiavi associate a vendor che non riconosci più, è il momento di fare pulizia con criterio, non di aggiungere altra roba nel portachiavi globale.

Procedura corretta: migrare una chiave da apt-key a signed-by

Prendiamo il caso tipico: un repository di terze parti installato su Debian 11 o Kali Linux con una chiave ancora gestita in modo legacy. La migrazione si fa in tre mosse: estrazione della chiave, salvataggio nel posto giusto, aggiornamento della sorgente APT.

1) Individua il repository interessato. Controlla i file in /etc/apt/sources.list.d/ e la configurazione principale:

grep -RIn --color=auto 'deb ' /etc/apt/sources.list /etc/apt/sources.list.d/

Annota la riga del repository che genera l’avviso. Serve a collegare chiave e origine senza ambiguità.

2) Esporta la chiave dal trust store legacy. Se conosci l’ID della chiave, puoi esportarla e convertirla nel formato gestibile da APT moderno. Esempio generico:

sudo apt-key export <KEYID> | sudo gpg --dearmor -o /usr/share/keyrings/vendor-archive-keyring.gpg

Se il repository fornisce già una chiave pubblica scaricabile, è meglio partire da quella e non dal portachiavi globale. In quel caso scarichi il file, lo converti se serve, e lo salvi in /usr/share/keyrings/ con permessi di lettura per APT.

3) Aggiorna la riga del repository usando signed-by. Esempio:

deb [signed-by=/usr/share/keyrings/vendor-archive-keyring.gpg] https://example.repo/debian stable main

Se il repository è in un file dedicato, modifica quel file con il tuo editor. Se usi il file principale, fai prima un backup. La modifica è piccola, ma un errore di sintassi nel formato della riga APT blocca l’update.

4) Verifica i permessi del keyring. APT deve poter leggere il file, ma non c’è motivo di renderlo scrivibile da altri. Un’impostazione comune è:

sudo chmod 0644 /usr/share/keyrings/vendor-archive-keyring.gpg
sudo chown root:root /usr/share/keyrings/vendor-archive-keyring.gpg

5) Ricarica gli indici e controlla l’output.

sudo apt update

Se tutto è corretto, l’avviso sul legacy keyring sparisce e il repository continua a essere aggiornato. Se compare ancora il warning, il repository potrebbe essere referenziato da un altro file oppure la chiave è ancora presente in /etc/apt/trusted.gpg e APT sta usando quella vecchia associazione.

Caso Debian 11: pulizia ordinata delle chiavi vecchie

Su Debian 11 è frequente trovare installazioni che hanno subito vari passaggi di manutenzione nel tempo. Il rischio non è solo l’avviso: è la presenza di chiavi residue che non servono più. La strategia corretta è mappare repository e chiavi prima di rimuovere qualcosa.

Per capire quali file e repository sono coinvolti, controlla:

ls -l /etc/apt/trusted.gpg.d/
cat /etc/apt/sources.list
ls -l /etc/apt/sources.list.d/

Se un vendor ha il proprio file .gpg in /usr/share/keyrings/, lascia perdere il portachiavi globale e aggiorna solo la riga del repository. Se invece trovi chiavi in /etc/apt/trusted.gpg.d/ senza un chiaro legame con un repository ancora attivo, valuta la rimozione solo dopo aver verificato che non servano ad altro.

Qui la prudenza conta: cancellare una chiave “a occhio” può fermare aggiornamenti legittimi. La verifica minima prima di rimuovere è sempre la stessa: quale repository la usa, in quale file, con quale nome, e se l’output di apt update resta pulito dopo la modifica.

Caso Kali Linux: repository ufficiale e terze parti

Kali ha una base abbastanza lineare, ma molti ambienti includono repository aggiuntivi per strumenti specifici. Il problema nasce quando si mescolano istruzioni vecchie con il repository ufficiale. La configurazione standard di Kali non richiede di affidarsi a chiavi disperse nel trust store globale per ogni aggiunta temporanea.

Se devi aggiungere un repository esterno, mantieni il keyring vicino alla sorgente e documenta il motivo dell’eccezione. Un approccio pulito è creare un file in /usr/share/keyrings/ con nome descrittivo, poi scrivere la riga APT in /etc/apt/sources.list.d/ con signed-by=. In questo modo, la manutenzione futura è più semplice e il rischio di fiducia eccessiva resta contenuto.

Se l’avviso compare dopo un upgrade del sistema e non dopo l’aggiunta di un nuovo repository, controlla anche eventuali vecchi file sotto /etc/apt/trusted.gpg.d/. Su Kali capita spesso di trovare residui di installazioni precedenti o guide seguite anni fa. La soluzione non è “nascondere” il warning, ma riallineare la configurazione al modello attuale.

Esempio completo di migrazione pulita

Supponiamo di avere un repository esterno per un pacchetto applicativo. Il flusso corretto è questo:

1. Recupera la chiave pubblica del vendor da una fonte affidabile.
2. Convertila in formato keyring con gpg --dearmor se necessario.
3. Salvala in /usr/share/keyrings/vendor-archive-keyring.gpg.
4. Modifica il file del repository in /etc/apt/sources.list.d/vendor.list aggiungendo signed-by=/usr/share/keyrings/vendor-archive-keyring.gpg.
5. Esegui sudo apt update e verifica che non ci siano warning legacy.

Un esempio pratico di file repository potrebbe essere:

deb [signed-by=/usr/share/keyrings/vendor-archive-keyring.gpg] https://repo.vendor.tld/debian bookworm main

Su Debian 11 il nome della suite potrebbe essere bullseye; su Kali dipende dal canale usato. Non copiare a caso la suite da una guida. Verifica sempre il repository ufficiale del vendor e il nome corretto della distribuzione supportata.

Errori comuni che fanno perdere tempo

Il primo errore è lasciare la chiave in /etc/apt/trusted.gpg e aggiungere comunque signed-by. In quel caso hai solo duplicato la fiducia e non hai davvero chiuso il problema. Il secondo errore è mettere il keyring in un percorso casuale senza permessi coerenti, così APT non lo legge e l’update fallisce in silenzio o con messaggi poco chiari.

Un altro errore tipico è confondere il warning sull’apt-key deprecato con un problema di firma del repository. Sono cose diverse. Se la firma è sbagliata, APT ti segnala un errore di verifica. Se invece la chiave è ancora nel trust store vecchio, ti avvisa che il metodo è deprecato ma non sempre blocca il download. La differenza importa, perché la correzione è diversa.

Infine, non usare keyserver pubblici alla cieca per recuperare chiavi di terze parti. Oltre a essere un’abitudine vecchia, introduce più punti di fallimento e più possibilità di prendere la chiave sbagliata. Meglio scaricare la chiave dal sito ufficiale del vendor o da una fonte documentata nel progetto.

Verifica finale e rollback ragionato

Dopo la migrazione, il controllo minimo è doppio: sudo apt update senza warning legacy e presenza del file keyring nel percorso previsto. Se vuoi una verifica più precisa, controlla che la riga del repository punti davvero al file giusto e che non restino copie inutili della chiave nel trust store globale.

grep -RIn --color=auto 'signed-by=' /etc/apt/sources.list /etc/apt/sources.list.d/
ls -l /usr/share/keyrings/vendor-archive-keyring.gpg

Il rollback, se serve, è semplice: ripristina il file repository precedente dal backup e rimetti temporaneamente la vecchia configurazione solo per isolare il problema. Non è il punto di arrivo, ma può servire per distinguere un errore di sintassi da un problema di chiave. Una volta chiarito, ripeti la migrazione in modo ordinato.

Assunzione operativa: i repository esterni sono legittimi e documentati; se manca la fonte della chiave o il vendor non indica un canale affidabile, il passo corretto è sospendere l’aggiunta del repository e recuperare prima il riferimento ufficiale.