Come correggere la firma GPG scaduta del repo MySQL su apt

Perché succede

Quando apt segnala una firma GPG scaduta per il repository MySQL, il problema non è quasi mai il pacchetto in sé: è la chiave di firma del repository che è cambiata, è scaduta oppure non viene più considerata valida dal sistema. In pratica, il gestore pacchetti blocca gli aggiornamenti per proteggerti da sorgenti non verificabili.

È un errore comune dopo il rinnovo delle chiavi di un vendor o quando si usa una configurazione vecchia nel file delle sorgenti. La soluzione corretta è aggiornare la chiave e, se serve, sistemare il riferimento del repository in modo pulito e verificabile.

Prima verifica l’errore esatto

Apri il terminale e lancia un aggiornamento per leggere il messaggio preciso:

sudo apt update

Se il problema è davvero la firma del repo MySQL, potresti vedere messaggi simili a:

NO_PUBKEY ...

oppure:

EXPKEYSIG ...

oppure ancora un avviso che indica che il repository non può essere verificato. È importante distinguere tra chiave mancante, chiave scaduta e repository configurato male, perché il fix è quasi lo stesso ma la verifica finale cambia.

Controlla quale sorgente MySQL stai usando

Su Ubuntu e Debian, il repository MySQL può essere definito in uno o più file sotto /etc/apt/sources.list e /etc/apt/sources.list.d/. Prima di modificare qualcosa, conviene capire dove punta il sistema.

grep -RniE 'mysql|repo.mysql.com' /etc/apt/sources.list /etc/apt/sources.list.d/

Esito atteso: trovi una riga che punta al repository ufficiale MySQL, spesso con una distribuzione tipo mysql-8.0 o simile.

Se il file è presente ma il repository non è più corretto per la tua distribuzione, anche la chiave giusta non basta: va sistemata la sorgente.

Soluzione consigliata: aggiorna la chiave in modo corretto

La strada più pulita è usare il keyring dedicato e non il vecchio metodo con apt-key, che oggi è deprecato. Se il sistema usa ancora una configurazione vecchia, conviene migrare al formato moderno.

Prima fai un backup del file di repository, se lo modificherai:

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

Se il file si chiama diversamente, sostituisci il nome con quello trovato al controllo precedente.

Scarica la chiave ufficiale MySQL e salvala come keyring locale:

curl -fsSL https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/mysql-archive-keyring.gpg > /dev/null

Questo comando crea un keyring leggibile da apt. Se la tua versione del repository usa una chiave diversa, il sito MySQL può indicare il file corretto. Il punto chiave è usare un keyring locale e referenziarlo nella sorgente.

Ora modifica il file del repository per usare signed-by. Un esempio tipico:

deb [signed-by=/usr/share/keyrings/mysql-archive-keyring.gpg] http://repo.mysql.com/apt/ubuntu/ jammy mysql-8.0

Su Debian o su una release diversa, cambiano la distribuzione e talvolta il componente, ma la struttura resta la stessa.

Se vuoi farlo con un editor:

sudo nano /etc/apt/sources.list.d/mysql.list

Inserisci o correggi la riga del repository, poi salva e chiudi.

Ricarica gli indici e verifica

Dopo la modifica, aggiorna la cache dei pacchetti:

sudo apt update

Esito atteso: l’errore GPG non deve più comparire e il repository MySQL deve essere letto correttamente.

Se vuoi un controllo più mirato, verifica che il repository venga visto come attendibile e che non ci siano warning sulla chiave:

apt-cache policy | sed -n '/repo.mysql.com/,+8p'

Esito atteso: vedi il repository MySQL e nessun errore legato a firma o chiave scaduta.

Se usi una versione vecchia di Ubuntu o Debian

Su sistemi non recenti, il problema può essere più complesso: il repository MySQL potrebbe non offrire più una combinazione compatibile con la tua release oppure la chiave fornita dal vendor può essere cambiata nel tempo. In questi casi, prima di forzare installazioni, conviene verificare tre cose:

1. La versione del sistema operativo è ancora supportata.
2. Il repository MySQL è quello giusto per quella release.
3. La chiave è referenziata con signed-by e non con metodi obsoleti.

Puoi controllare la versione con:

cat /etc/os-release

Esito atteso: conosci il nome della release, ad esempio Ubuntu 22.04 o Debian 12, e puoi confrontarla con la riga del repository.

Alternativa B: reinstallare il pacchetto di configurazione MySQL

Se il repository è stato impostato con il pacchetto ufficiale mysql-apt-config, può essere più semplice reinstallarlo e lasciargli rigenerare la configurazione corretta. Questa è spesso la via più ordinata quando la configurazione si è incasinata nel tempo.

Scarica il pacchetto ufficiale dal sito MySQL e installalo:

sudo dpkg -i mysql-apt-config_*.deb

Durante la configurazione scegli la versione di MySQL che ti serve e conferma il repository corretto per la tua distribuzione. Poi aggiorna gli indici:

sudo apt update

Esito atteso: il repository viene ricreato con la chiave corretta e il warning GPG scompare.

Questa opzione è utile quando il file sorgente è stato modificato a mano più volte o quando non sei sicuro di quale chiave sia stata installata in passato.

Se compare ancora l’errore

Se dopo l’aggiornamento della chiave l’errore persiste, fai un controllo più preciso sulla riga del repository e sul keyring usato.

cat /etc/apt/sources.list.d/mysql.list

Controlla che la riga contenga davvero signed-by=/usr/share/keyrings/mysql-archive-keyring.gpg e che il file esista:

ls -l /usr/share/keyrings/mysql-archive-keyring.gpg

Esito atteso: il file c’è, ha dimensione non nulla e appartiene a root.

Se il file non esiste, ricrea il keyring. Se esiste ma il warning continua, probabilmente la riga del repository punta ancora a una chiave vecchia, oppure il repository non corrisponde alla release installata.

Verifica della chiave importata

Per controllare che il keyring contenga davvero una chiave valida, puoi ispezionarlo con:

gpg --show-keys /usr/share/keyrings/mysql-archive-keyring.gpg

Esito atteso: viene mostrata una chiave pubblica coerente con MySQL, con data di creazione e, se presente, una scadenza non già superata.

Se la chiave risulta scaduta, devi sostituirla con quella più recente indicata dal vendor. Non conviene ignorare il messaggio o disabilitare la verifica: perderesti la protezione sull’integrità dei pacchetti.

Installazione o aggiornamento dei pacchetti MySQL

Quando il repository torna valido, puoi procedere con il normale aggiornamento:

sudo apt update && sudo apt upgrade

Se devi installare MySQL o aggiornare il server, esegui il comando specifico solo dopo aver confermato che il repository non genera più errori.

Se il sistema è in produzione, meglio fare prima un backup dei dati e verificare che non ci siano job di manutenzione o repliche attive.

Buone pratiche per evitare il problema in futuro

Per ridurre il rischio di ritrovarti con una chiave scaduta o una sorgente rotta, tieni queste abitudini:

• Usa sempre il metodo signed-by con un keyring in /usr/share/keyrings/.
• Evita apt-key per nuove configurazioni.
• Controlla periodicamente i repository di terze parti con apt update.
• Documenta la versione del sistema e la versione del repository installato.
• Rimuovi vecchie sorgenti che non servono più.

Questo approccio rende più semplice capire subito da dove arriva un errore di firma e limita gli interventi d’emergenza.

Checklist rapida finale

1. Esegui sudo apt update e conferma che l’errore GPG sia sparito.
2. Verifica la riga del repo MySQL in /etc/apt/sources.list.d/.
3. Usa un keyring locale con signed-by.
4. Controlla che la chiave importata sia valida con gpg --show-keys.
5. Solo dopo, procedi con l’installazione o l’upgrade dei pacchetti MySQL.

Conclusione operativa

La correzione giusta non è “saltare” la verifica, ma aggiornare il trust path del repository in modo ordinato. Nella maggior parte dei casi basta importare la nuova chiave, collegarla alla sorgente con signed-by e rilanciare apt update. Se il problema resta, il vero indizio da inseguire non è la firma in sé, ma la compatibilità tra versione del sistema, riga del repository e keyring usato.