Inizia identificando il repository che ha generato l'avviso, quindi correggi la chiave o la configurazione di tale repository. Non disabilitare i controlli della firma di APT. Il messaggio "Le seguenti firme non possono essere verificate" significa che APT non può confermare che i metadati del repository siano stati firmati da una chiave di cui si fida. Finché la firma non viene verificata, APT potrebbe rifiutarsi di utilizzare tale origine. L'aggiunta di una chiave casuale o l'impostazione di un'origine come attendibile può nascondere l'avviso, ma rimuove la protezione che dovrebbe fornire.
Ad esempio, supponiamo che sudo apt updatei report NO_PUBKEYper il repository di un fornitore di browser vengano aggiornati correttamente, mentre le righe di archivio di Ubuntu si aggiornano senza problemi. La soluzione più probabile è installare la chiave di firma attualmente pubblicata da quel fornitore e limitarne l'ambito a quel repository. Reinstallare il portachiavi di archivio di Ubuntu non risolverebbe un problema con una chiave di terze parti. I comandi seguenti sono modelli: sostituire i dettagli del repository di esempio con i valori tratti dalle istruzioni ufficiali del produttore del software.
Leggere l'errore esatto prima di modificare i tasti.
Esegui il comando di aggiornamento e annota l'URL del repository e il codice di errore sulle stesse righe di output:
sudo apt update
APT identifica normalmente una sorgente tramite il suo URL e la suite di rilascio, ad esempio nobleo jammy. Se è configurata più di una sorgente, potrebbero essere visualizzati diversi errori. Associa ciascun messaggio al repository corrispondente prima di apportare modifiche. Queste firme comuni indicano cause diverse:
| Messaggio o indizio | Significato probabile | Prima azione |
NO_PUBKEY | La chiave di firma pubblica necessaria per quel repository non è disponibile per APT, oppure la sorgente non punta al file della chiave. | Identifica il proprietario del repository e ottieni la sua chiave corrente seguendo le istruzioni ufficiali dell'editore. |
EXPKEYSIG | La chiave utilizzata per la firma è scaduta oppure è necessario aggiornare la configurazione della firma del repository. | Controlla l'avviso di rotazione delle chiavi pubblicato dall'editore; non continuare a reinstallare la chiave scaduta. |
BADSIG | La firma non corrisponde ai metadati ricevuti da APT. Potrebbe trattarsi di un mirror non aggiornato, di un proxy, di un download parziale o di un problema lato repository. | Riprova dopo aver verificato l'origine, il percorso di rete e i file di indice memorizzati nella cache. |
Release file is not valid yeto formulazione temporale simile | L'orologio di sistema potrebbe non essere sincronizzato con il timestamp firmato del repository. | Verificare la data di sistema, il fuso orario e la sincronizzazione dell'ora. |
| La chiave è presente, ma la sorgente segnala ancora una chiave sconosciuta. | La sorgente potrebbe fare riferimento a un portachiavi diverso, a un percorso errato o a un file chiave illeggibile da APT. | Signed-ByVerifica le impostazioni e le autorizzazioni del portachiavi della sorgente . |
Se l'errore fa riferimento all'ora, controlla prima l'orologio di sistema.
Le firme e i metadati del repository hanno periodi di validità. Un server ripristinato da uno snapshot precedente, un computer con dual-boot o una macchina con un servizio orario non funzionante potrebbero avere un orologio talmente sfasato da rendere i metadati correnti non validi. Controlla l'ora di sistema:
timedatectl status
Verificare che la data e l'ora visualizzate siano corrette e che la sincronizzazione dell'ora sia attiva. Se l'orologio non è corretto, correggere il servizio orario dell'host o abilitare il metodo di sincronizzazione dell'ora di rete configurato, quindi riprovare sudo apt update. Evitare di impostare manualmente una data approssimativa: l'orologio deve riflettere l'ora reale. La correzione dell'ora non risolverà un problema con una chiave di repository mancante o scaduta, quindi se il messaggio di NO_PUBKEYerrore persiste EXPKEYSIG, continuare con i passaggi relativi alla chiave.
Risolvere un problema con una chiave di repository di terze parti mancante o scaduta
Le attuali linee guida di Ubuntu raccomandano di archiviare le chiavi di terze parti in un portachiavi dedicato e di fare riferimento a tale chiave dalla sorgente corrispondente Signed-By. Questo limita le chiavi che possono autenticare quel repository. Ubuntu descrive questo approccio nella sua guida ai repository di terze parti e APT documenta come Signed-Byvengono gestiti gli ambiti di verifica nel manuale sources.list .
1. Individua la fonte che ha generato l'errore
Elenca le voci del repository e cerca l'host mostrato nell'output di APT:
grep -RniE '^[[:space:]]*(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
Ubuntu 24.04 e versioni successive utilizzano comunemente file deb822 con estensione .sources; le versioni precedenti utilizzano comunemente file a riga singola con estensione .list. La documentazione sulla gestione dei pacchetti di Ubuntu descrive questi formati sorgente. Non modificare la voce dell'archivio di Ubuntu per riparare un repository di fornitore non correlato.
2. Ottieni e verifica la chiave corrente dell'editore
Apri la pagina ufficiale di configurazione del repository del produttore del software e verifica che siano indicati l'URL del repository, la versione di Ubuntu supportata, la posizione di download della chiave di firma e l'impronta digitale completa della chiave. Scarica la chiave solo da una fonte identificata dal produttore. Confronta l'impronta digitale completa, non solo il breve ID esadecimale mostrato dopo NO_PUBKEY. Il manuale di sicurezza di APT sottolinea l'importanza di ottenere le chiavi tramite un canale affidabile; affidarsi alla chiave sbagliata comprometterebbe la verifica del repository.
L'esempio seguente utilizza una chiave codificata in ASCII. Sostituisci l'URL e il nome del file di esempio con i valori ufficiali dell'editore:
curl -fsSLo /tmp/vendor-archive.asc https://packages.vendor.example/ubuntu/archive-key.asc
gpg --show-keys --with-fingerprint /tmp/vendor-archive.asc
Procedi solo se l'impronta digitale visualizzata corrisponde a quella documentata dall'editore. Convertila in un portachiavi binario e posizionala nella directory locale dei portachiavi di APT:
sudo install -d -m 0755 /etc/apt/keyrings
gpg --dearmor --output /tmp/vendor-archive.gpg /tmp/vendor-archive.asc
sudo install -m 0644 /tmp/vendor-archive.gpg /etc/apt/keyrings/vendor-archive-keyring.gpg
Il dominio di esempio è puramente illustrativo e non scaricherà una chiave di licenza reale del fornitore. Utilizzare l'URL esatto della chiave verificata fornita dal produttore del software. Non utilizzare i risultati di una ricerca su un server di chiavi come sostituto per la verifica della proprietà della chiave.
3. Definisci l'ambito della chiave nel codice sorgente del repository
Per una voce su una sola riga .list, il modello è:
deb [signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] https://packages.vendor.example/ubuntu noble main
Per un file deb822 .sources, i campi corrispondenti hanno questo aspetto:
Types: deb
URIs: https://packages.vendor.example/ubuntu
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive-keyring.gpg
Questi sono modelli, non voci sorgente universalmente valide. Mantieni l'URI, la suite e i componenti dalle istruzioni di configurazione ufficiali del fornitore; un nome in codice Ubuntu errato può creare conflitti di pacchetti anche quando la chiave è valida. Assicurati che il percorso del portachiavi corrisponda al file installato. Il portachiavi deve essere leggibile dall'utente non privilegiato di APT _apt, motivo per cui l'esempio lo installa con la modalità 0644. Rimuovi o correggi le voci duplicate per lo stesso repository in modo che una vecchia voce senza ambito non continui a produrre l'avviso.
Il comando APT apt-keyè obsoleto per la configurazione ordinaria dei repository. Evitate le guide che aggiungono chiavi di terze parti a livello globale apt-key advo che inseriscono tutte le chiavi dei fornitori in un portachiavi comune e affidabile. Una Signed-Byvoce con ambito specifico rende più chiara la relazione di fiducia e riduce l'impatto della fiducia riposta in una singola chiave del repository.
Se l'avviso riguarda l'archivio di Ubuntu
Innanzitutto, verifica che la suite di repository corrisponda alla versione di Ubuntu installata e che l'orologio di sistema sia corretto. Le chiavi di firma degli archivi di Ubuntu sono fornite dal ubuntu-keyringpacchetto. Se il portachiavi installato è danneggiato o obsoleto e APT è ancora in grado di scaricare e verificare i pacchetti da una sorgente Ubuntu configurata valida, reinstallalo con:
sudo apt install --reinstall ubuntu-keyring
Quindi esegui sudo apt updatenuovamente il processo. Se l'unica fonte che causa l'errore è un archivio di rilascio obsoleto o un mirror che fornisce metadati incoerenti, la reinstallazione del portachiavi potrebbe non essere d'aiuto. Verifica il supporto per le release di Ubuntu e la configurazione del repository prima di modificare le chiavi. Non sostituire la chiave dell'archivio di Ubuntu con una chiave scaricata da un sito non correlato né disabilitare la verifica per forzare un aggiornamento.
Cancella gli indici memorizzati nella cache solo in caso di mancata corrispondenza dei metadati.
Se APT segnala BADSIGun problema dopo un'interruzione temporanea della rete o un problema con un mirror/proxy, gli elenchi dei pacchetti memorizzati nella cache locale potrebbero essere incompleti o incoerenti. Dopo aver verificato che la sorgente configurata sia legittima, cancellare solo i file di indice APT memorizzati nella cache e scaricarli nuovamente.
sudo rm -rf /var/lib/apt/lists/*
sudo apt update
Questa operazione rimuove gli indici del repository scaricato, non i pacchetti installati. APT ricostruisce gli indici al successivo aggiornamento. Se BADSIGil problema si ripresenta immediatamente, interrompere la pulizia ripetuta: verificare se un proxy di rete, un gateway di caching o un mirror sta riscrivendo o fornendo metadati non corrispondenti e controllare lo stato del repository con il suo editore. Eliminare ripetutamente gli indici non corregge una firma pubblicata in modo errato dal repository stesso.
Conferma la riparazione e mantieni la protezione attiva
Esegui sudo apt updatenuovamente il comando e verifica che il repository interessato venga completato senza avvisi di tipo NO_PUBKEY, EXPKEYSIG, BADSIG, o di verifica della firma. Quindi controlla un pacchetto da quella sorgente con apt-cache policy package-name, sostituendo il nome con un pacchetto effettivo. Conferma che la sua versione candidata provenga dal repository previsto prima di installarlo o aggiornarlo.
Non utilizzare trusted=yes, allow-insecure=yes, --allow-unauthenticated, o opzioni simili come soluzione permanente. Il controllo della firma di APT verifica che i metadati del repository siano firmati da una chiave di cui hai scelto di fidarti; disabilitandolo, APT non sarà più in grado di fornire tale controllo di integrità. Il manuale di APT Secure spiega la catena di autenticazione dell'archivio e i suoi limiti. Se l'editore ha ritirato un repository, ha smesso di firmare i metadati o non fornisce un'impronta digitale della chiave verificabile, rimuovi o disabilita tale fonte anziché aggirare la verifica.
Documentazione verificata il 6 ottobre 2026. I formati dei repository di Ubuntu e le raccomandazioni per la gestione delle chiavi possono variare a seconda della versione; si consiglia di utilizzare la documentazione della versione di Ubuntu installata e le istruzioni aggiornate del fornitore del repository.