Risolvere l’avviso apt-key deprecato su Ubuntu

Su Ubuntu, l’avviso apt-key deprecato segnala un problema reale di gestione della fiducia dei repository: la chiave non dovrebbe più stare nel keyring globale di APT, perché così finisce per autorizzare tutti i sorgenti configurati sul sistema. La correzione giusta non è “zittire il warning”, ma spostare ogni repository sul modello signed-by, dove la chiave è associata in modo esplicito a una singola origine.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Il punto pratico è semplice: se il tuo sistema mostra un messaggio del tipo apt-key is deprecated o continua a usare chiavi in /etc/apt/trusted.gpg e in /etc/apt/trusted.gpg.d/ senza controllo granulare, stai mantenendo una fiducia troppo ampia. Su un server questo è un problema di igiene operativa; su una workstation è anche un tema di superficie d’attacco. La migrazione è fattibile senza rompere gli aggiornamenti, ma va fatta con ordine.

Perché apt-key è un problema su Ubuntu moderno

apt-key serviva per importare chiavi GPG usate da APT nella verifica dei pacchetti. Il limite è strutturale: la chiave importata nel trust store globale vale per tutti i repository, non solo per quello previsto. Se una chiave viene compromessa o se un repository terzo viene configurato male, il raggio d’azione è più ampio del necessario.

Le versioni recenti di Ubuntu e Debian spingono verso una separazione netta: la chiave deve stare in un file dedicato, leggibile da APT, e il repository deve dichiarare esplicitamente quale chiave usare. In pratica si passa da una fiducia “di sistema” a una fiducia “per sorgente”.

Questo approccio ha tre vantaggi concreti:

• riduce l’impatto di una chiave compromessa;
• rende più facile capire quale repository usa quale chiave;
• evita warning durante apt update e prepara il sistema ai comportamenti futuri di APT.

Come riconoscere il caso che stai gestendo

Il warning appare spesso dopo un apt update. Esempi tipici:

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

Oppure trovi repository terzi configurati in /etc/apt/sources.list o in /etc/apt/sources.list.d/*.list senza parametro signed-by. In quel caso APT userà il trust store globale e continuerà a produrre il warning finché non migri la sorgente.

Prima di toccare la configurazione, conviene capire quali chiavi sono presenti e quali repository le consumano. Non serve fare ipotesi: basta leggere gli artefatti locali.

Inventario rapido di chiavi e repository

Il primo controllo è vedere quali chiavi sono ancora nel keyring legacy. Su Ubuntu moderno, il file storico è /etc/apt/trusted.gpg; le chiavi separate stanno in /etc/apt/trusted.gpg.d/.

sudo apt-key list

Il comando funziona ancora in molti ambienti, ma proprio perché è deprecato va usato solo come strumento di ispezione temporanea. Se vuoi una fotografia più pulita, controlla direttamente i file presenti:

sudo ls -l /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d/

Per capire quali repository sono configurati, ispeziona le sorgenti:

grep -RhsE '^[^#].*(deb|deb-src)' /etc/apt/sources.list /etc/apt/sources.list.d/

Se vuoi incrociare repository e warning in modo più diretto, l’output di apt update è spesso sufficiente. Cerca la riga che cita il repository e il keyring legacy. Quello è il punto da correggere, non il sistema intero.

Strategia corretta: una chiave per un repository

La migrazione pulita segue questo schema: esporti la chiave del repository in un file dedicato, la converti in formato leggibile da APT se necessario, la posizioni in una directory stabile come /etc/apt/keyrings/ e modifichi la riga del repository per usare signed-by=.

Su Ubuntu recente la directory consigliata è /etc/apt/keyrings/. Se non esiste, la puoi creare. Non mettere chiavi in /usr/share/keyrings/ a meno che il pacchetto le distribuisca già lì: per repository gestiti manualmente, /etc/apt/keyrings/ è più chiaro e più facile da mantenere.

Migrazione passo per passo con esempio reale

Immagina un repository esterno che oggi è configurato così:

deb https://download.example.org/linux/ubuntu jammy main

e la sua chiave è stata importata nel trust store globale. La correzione consiste nel separare la chiave e legarla alla sorgente.

1. Crea la directory per le chiavi, se non esiste.

sudo install -d -m 0755 /etc/apt/keyrings

1. Recupera la chiave del repository da una fonte affidabile. Se il vendor pubblica un file ASCII armored, puoi salvarlo in locale e convertirlo in formato binario dearmored, che APT gestisce bene.

curl -fsSL https://download.example.org/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/example-repo.gpg

Se il repository distribuisce la chiave in un percorso diverso, adatta l’URL ma mantieni il principio: scarica solo da HTTPS, verifica la provenienza e non incollare chiavi a mano in file di configurazione. Se la chiave è già disponibile in formato binario, puoi copiarla direttamente in /etc/apt/keyrings/.

1. Rendi il file leggibile da APT, ma non eseguibile e non scrivibile da utenti non privilegiati.

sudo chmod 0644 /etc/apt/keyrings/example-repo.gpg

1. Modifica la riga del repository aggiungendo signed-by.

deb [signed-by=/etc/apt/keyrings/example-repo.gpg] https://download.example.org/linux/ubuntu jammy main

Se il repository è in un file separato sotto /etc/apt/sources.list.d/, aggiorna quel file direttamente. È preferibile rispetto a toccare /etc/apt/sources.list se il sorgente è di terze parti: separazione netta, rollback più semplice.

1. Esegui un aggiornamento e verifica che il warning sia sparito per quel repository.

sudo apt update

Se tutto è corretto, non dovresti più vedere il messaggio sul keyring legacy per quella sorgente. Se il warning resta, significa che c’è ancora un’altra entry che usa la stessa chiave o che la chiave è stata importata anche altrove.

Come trattare le chiavi già presenti in trusted.gpg

Il caso più comune è trovare una chiave “vecchia” nel keyring globale e volerla spostare senza rompere gli aggiornamenti. Qui il principio è: prima aggiungi la nuova configurazione con signed-by, poi validi, poi rimuovi la vecchia chiave solo quando sei sicuro che il repository non dipende più dal trust store globale.

Per individuare la chiave da rimuovere, l’output di apt-key list mostra gli ID e i fingerprint. Annotali, poi esporta il blocco corrispondente in un file dedicato se il vendor non fornisce già una chiave aggiornata.

sudo apt-key del <KEYID>

Questo comando va usato con cautela e solo dopo aver applicato la nuova configurazione. Non è la prima mossa, è l’ultima. Se lo esegui troppo presto, il repository smette di funzionare e ti ritrovi con un errore di firma durante apt update.

Come esportare una chiave dal trust store legacy

Se la chiave è già presente localmente e non hai un file esterno affidabile da cui riscaricarla, puoi esportarla e convertirla. Questa è una soluzione di transizione, non il modello ideale a lungo termine, ma evita di reimpostare tutto da zero.

sudo apt-key export <KEYID> | sudo gpg --dearmor -o /etc/apt/keyrings/example-repo.gpg

Dopo l’esportazione, verifica che il file sia stato creato e abbia dimensioni plausibili:

ls -l /etc/apt/keyrings/example-repo.gpg

Se il file è zero byte o manca, qualcosa è andato storto nella pipeline. In quel caso il repository non sarà verificabile e apt update fallirà per firma mancante o non valida.

Repository multipli e chiavi condivise: quando fermarsi e rifattorizzare

Capita spesso di trovare una singola chiave usata per più repository dello stesso vendor. Non è sempre sbagliato, ma va valutato. Se il vendor separa davvero i canali, meglio separare anche le chiavi. Se invece il vendor pubblica un unico archivio firmato con la stessa identità, puoi mantenere una chiave unica, ma sempre con signed-by per quel vendor e non nel trust store globale.

Un errore comune è creare un file .list con più repository e la stessa chiave senza capire se i pacchetti hanno lo stesso livello di fiducia. La regola pratica è: se il contenuto è amministrato da soggetti diversi, separa chiavi e sorgenti. Se il contenuto è dello stesso vendor e dello stesso ciclo di rilascio, una chiave condivisa può essere accettabile, ma sempre con perimetro esplicito.

Quando usare .sources invece di .list

Su Ubuntu recenti puoi gestire i repository anche tramite il formato deb822, cioè file .sources. È più verboso ma più leggibile e più adatto a configurazioni complesse. In un file .sources puoi dichiarare chiaramente URIs, Suites, Components e Signed-By.

Esempio minimale:

Types: deb
URIs: https://download.example.org/linux/ubuntu
Suites: jammy
Components: main
Signed-By: /etc/apt/keyrings/example-repo.gpg

Il vantaggio del formato deb822 è che riduce l’ambiguità e rende più semplice il versioning della configurazione. Se stai gestendo più repository su una macchina server, spesso è la scelta più pulita. Se invece hai già molte entry storiche in formato classico, non c’è obbligo di migrare tutto subito: puoi correggere il warning repository per repository.

Verifiche post-migrazione che non vanno saltate

Dopo aver aggiornato la configurazione, non fermarti al fatto che il warning sia sparito. Devi verificare che APT legga davvero la nuova chiave e che il repository risulti affidabile con il perimetro corretto.

1. Esegui sudo apt update e controlla che non compaiano più warning sul keyring legacy.

2. Verifica che i pacchetti del repository siano ancora installabili con sudo apt policy nome-pacchetto.

3. Controlla che il file in /etc/apt/sources.list.d/ o .sources contenga effettivamente signed-by o Signed-By.

4. Se usi automazione, integra il controllo nel tuo sistema di configurazione, così il warning non ricompare dopo un provisioning o un upgrade.

Un controllo utile, se vuoi essere rigoroso, è cercare ancora riferimenti al keyring globale nel sistema:

grep -RhsE 'trusted\.gpg|apt-key' /etc/apt/

Se non esce nulla di rilevante, hai ridotto la dipendenza dal modello legacy. Se invece trovi ancora riferimenti, c’è almeno una sorgente non migrata.

Rollback semplice se qualcosa si rompe

Il rollback corretto è banale proprio perché la modifica deve essere piccola. Se il repository smette di funzionare dopo l’introduzione di signed-by, puoi ripristinare temporaneamente la riga precedente, rieseguire apt update e riprendere l’analisi con più calma. Questo però va fatto solo come misura di emergenza e non come soluzione definitiva.

Se hai modificato un file in /etc/apt/sources.list.d/, tieni una copia prima della variazione:

sudo cp /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.bak

In caso di errore, ripristina il file e rilancia l’update:

sudo mv /etc/apt/sources.list.d/example.list.bak /etc/apt/sources.list.d/example.list
sudo apt update

Se il problema è la chiave, il rollback può anche consistere nel ripristinare temporaneamente il vecchio keyring solo per sbloccare gli aggiornamenti, ma va considerato un ponte operativo, non uno stato finale. L’obiettivo resta sempre il passaggio a chiavi dedicate e sorgenti esplicite.

Errori tipici da evitare

Il primo errore è lasciare la chiave in /etc/apt/trusted.gpg “per comodità”. È esattamente ciò che produce il warning e ciò che APT vuole abbandonare. Il secondo errore è copiare una chiave in un file qualsiasi senza dare il permesso corretto: APT deve poterla leggere, ma non devi trasformarla in un file modificabile da utenti non privilegiati.

Un altro errore frequente è usare una chiave sbagliata ma compatibile con altri repository dello stesso vendor. In quel caso apt update può anche funzionare, ma stai allargando la fiducia oltre il necessario. Se il repository è diverso, la chiave deve essere diversa o almeno il perimetro deve essere chiaramente dichiarato.

Infine, non usare il warning come unico criterio. Il fatto che il messaggio sparisca non significa automaticamente che la trust chain sia corretta. Devi sempre verificare il file di configurazione, il percorso della chiave e il risultato di apt update.

Checklist operativa da riutilizzare su altri server

Quando devi correggere il warning su più host, la sequenza pratica è sempre la stessa:

1. identifica il repository che genera il warning con apt update;

2. localizza il file sorgente in /etc/apt/sources.list o /etc/apt/sources.list.d/;

3. scarica o esporta la chiave dedicata;

4. salvala in /etc/apt/keyrings/ con permessi lettura per APT;

5. aggiungi signed-by o Signed-By;

6. rilancia apt update e verifica l’assenza del warning;

7. rimuovi solo alla fine la chiave dal trust store legacy, se ancora presente.

Questa procedura è ripetibile, documentabile e adatta sia a una macchina singola sia a un parco server gestito con automation. In un contesto di produzione, il vantaggio vero non è solo eliminare un avviso: è riportare la fiducia dei repository dentro un perimetro chiaro, verificabile e facilmente auditabile.

Se stai standardizzando nuove installazioni Ubuntu, conviene applicare subito il modello /etc/apt/keyrings/ + signed-by per ogni repository esterno. Eviti debito tecnico, riduci i warning e non devi fare una migrazione massiva in seguito.