Cum se remediază eroarea GPG: Următoarele semnături nu au putut fi verificate în Ubuntu

Începeți prin a identifica depozitul care a generat avertismentul, apoi corectați cheia sau configurația depozitului respectiv. Nu dezactivați verificările de semnătură APT. Mesajul „Următoarele semnături nu au putut fi verificate” înseamnă că APT nu poate confirma că metadatele depozitului au fost semnate de o cheie în care are încredere. Până la verificarea semnăturii, APT poate refuza să utilizeze sursa respectivă. Adăugarea unei chei aleatorii sau setarea unei surse ca fiind de încredere poate ascunde avertismentul și, în același timp, poate elimina protecția pe care ar trebui să o ofere.

De exemplu, să presupunem că sudo apt updaterapoartele NO_PUBKEYpentru depozitul unui furnizor de browser se actualizează cu succes, în timp ce liniile de arhivă ale Ubuntu se actualizează cu succes. Soluția probabilă este instalarea cheii de semnare publicate în prezent de furnizorul respectiv și extinderea acesteia la depozitul respectiv. Reinstalarea cheilor de arhivă ale Ubuntu nu ar rezolva problema unei chei terțe. Comenzile de mai jos sunt șabloane: înlocuiți detaliile depozitului de exemplu cu valori din instrucțiunile oficiale ale editorului de software.

Citește eroarea exactă înainte de a schimba cheile

Executați comanda de actualizare și notați adresa URL a repozitoriului și codul de eroare pe aceleași linii de ieșire:

sudo apt update

APT identifică în mod normal o sursă prin adresa URL și suita de versiuni, cum ar fi noblesau jammy. Dacă sunt configurate mai multe surse, acestea pot afișa mai multe erori. Potriviți fiecare mesaj cu propriul depozit înainte de a face o modificare. Aceste semnături comune indică cauze diferite:

Verificați mai întâi ceasul sistemului când eroarea menționează ora

Semnăturile și metadatele depozitului au perioade de valabilitate. Un server restaurat dintr-o instantanee veche, un computer cu boot dual sau o mașină cu un serviciu de oră defect poate avea un ceas suficient de decalat pentru ca metadatele curente să pară nevalide. Verificați ora sistemului:

timedatectl status

Confirmați că data și ora afișate sunt corecte și că sincronizarea orei este activă. Dacă ceasul este greșit, corectați serviciul de oră al gazdei sau activați metoda configurată de sincronizare a orei în rețea, apoi încercați din nou sudo apt update. Evitați setarea manuală a unei date aproximative: ceasul ar trebui să reflecte ora reală. O corecție a orei nu va repara o cheie de depozit lipsă sau expirată, așa că, dacă mesajul rămâne o eroare NO_PUBKEYsau EXPKEYSIG, continuați cu pașii cheie relevanți.

Remediați o cheie de depozit terță parte lipsă sau expirată

Ghidul actual al Ubuntu recomandă stocarea cheilor terțe într-un keyring dedicat și referențierea cheii respective din sursa corespunzătoare cu Signed-By. Acest lucru limitează cheia care poate autentifica depozitul respectiv. Ubuntu descrie această abordare în ghidul său pentru depozite terțe , iar APT documentează modul Signed-Byde verificare a scopurilor în manualul sources.list .

1. Găsiți sursa care a generat eroarea

Listați intrările din repozitoriu și căutați gazda afișată în ieșirea APT:

grep -RniE '^[[:space:]]*(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Ubuntu 24.04 și versiunile ulterioare utilizează în mod obișnuit fișiere deb822 care se termină în .sources; versiunile mai vechi utilizează în mod obișnuit fișiere pe o singură linie care se termină în .list. Documentația de gestionare a pachetelor Ubuntu descrie aceste formate sursă. Nu editați intrarea din arhiva Ubuntu pentru a repara un depozit de furnizor fără legătură.

2. Obțineți și verificați cheia curentă a editorului

Deschideți pagina oficială de configurare a depozitului a editorului de software și confirmați că aceasta menționează adresa URL a depozitului, versiunea Ubuntu acceptată, locația de descărcare a cheii de semnare și amprenta completă a cheii. Descărcați cheia numai dintr-o sursă identificată de editor. Comparați amprenta completă, nu doar ID-ul hexazecimal scurt afișat după NO_PUBKEY. Manualul de securitate APT subliniază obținerea cheilor printr-un canal de încredere; încrederea în cheia greșită ar submina verificarea depozitului.

Următorul exemplu folosește o cheie blindată ASCII. Înlocuiți adresa URL și numele fișierului exemplu cu valorile oficiale ale editorului:

curl -fsSLo /tmp/vendor-archive.asc https://packages.vendor.example/ubuntu/archive-key.asc
gpg --show-keys --with-fingerprint /tmp/vendor-archive.asc

Continuați doar atunci când amprenta afișată se potrivește cu cea documentată de editor. Convertiți-o într-un keyring binar și plasați-o în directorul local al keyring-ului 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

Domeniul exemplu este ilustrativ și nu va descărca o cheie reală a furnizorului. Folosiți adresa URL exactă a cheii verificate, furnizată de producătorul real al software-ului. Nu utilizați un rezultat al căutării unui server de chei ca înlocuitor pentru confirmarea proprietății cheii.

3. Definiți domeniul de aplicare al cheii în sursa depozitului

Pentru o intrare pe o singură linie .list, modelul este:

deb [signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] https://packages.vendor.example/ubuntu noble main

Pentru un fișier deb822 .sources, câmpurile corespunzătoare arată astfel:

Types: deb
URIs: https://packages.vendor.example/ubuntu
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive-keyring.gpg

Acestea sunt șabloane, nu intrări sursă universal valabile. Păstrați URI-ul, suita și componentele din instrucțiunile oficiale de configurare ale furnizorului; un nume de cod Ubuntu greșit poate crea conflicte de pachete chiar și atunci când cheia este validă. Asigurați-vă că calea către inelul de chei se potrivește cu fișierul instalat. Inelul de chei trebuie să poată fi citit de _aptutilizatorul neprivilegiat al APT, motiv pentru care exemplul îl instalează cu modul 0644. Eliminați sau corectați intrările duplicate pentru același depozit, astfel încât o intrare veche fără scop să nu continue să genereze avertismentul.

Comanda APT apt-keyeste depreciată pentru configurarea obișnuită a repozitoriului. Evitați ghidurile care adaugă chei terțe la nivel global apt-key advsau plasează fiecare cheie a furnizorului într-un keyring comun de încredere. O Signed-Byintrare cu scop clarifică relația de încredere și reduce efectul acordării de încredere unei singure chei de repozitoriu.

Dacă avertismentul este pentru arhiva proprie a Ubuntu

Mai întâi verificați dacă suita de repozitorii corespunde cu versiunea Ubuntu instalată și dacă ceasul sistemului este corect. Cheile de semnare a arhivei Ubuntu sunt furnizate de ubuntu-keyringpachet. Dacă inelul de chei instalat este deteriorat sau învechit și APT poate încă descărca și verifica pachetele dintr-o sursă Ubuntu configurată validă, reinstalați-l cu:

sudo apt install --reinstall ubuntu-keyring

Apoi rulați sudo apt updatedin nou. Dacă singura sursă defectă este o arhivă de lansare învechită sau o versiune mirror care servește metadate inconsistente, reinstalarea keyring-ului s-ar putea să nu fie de ajutor. Verificați suportul pentru lansări și configurația repozitoriului Ubuntu înainte de a schimba cheile. Nu înlocuiți cheia arhivei Ubuntu cu o cheie descărcată de pe un site fără legătură și nu dezactivați verificarea pentru a forța o actualizare.

Ștergeți indexurile din cache doar pentru o nepotrivire de metadate

Dacă APT raportează BADSIGdupă o întrerupere temporară a rețelei sau o problemă cu mirror/proxy, listele de pachete din cache-ul local pot fi incomplete sau inconsistente. După confirmarea faptului că sursa configurată este legitimă, ștergeți doar fișierele index APT din cache și recuperați-le din nou:

sudo rm -rf /var/lib/apt/lists/*
sudo apt update

Aceasta metodă elimină indexurile depozitului descărcate, nu pachetele instalate. APT reconstruiește indexurile la următoarea actualizare. Dacă BADSIGreturnează imediat eroarea, oprește repetarea curățării: verifică dacă un proxy de rețea, un gateway de caching sau un mirror rescrie sau servește metadate nepotrivite și verifică starea depozitului cu editorul său. Ștergerea repetată a indexurilor nu remediază o semnătură pe care depozitul în sine o publică incorect.

Confirmați repararea și mențineți protecția activată

Executați sudo apt updatedin nou și verificați dacă depozitul afectat se finalizează fără avertismente de verificare a semnăturii NO_PUBKEY, EXPKEYSIG, BADSIG, sau . Apoi, verificați un pachet din sursa respectivă cu apt-cache policy package-name, înlocuind numele cu un pachet real. Confirmați că versiunea sa candidată provine din depozitul așteptat înainte de a-l instala sau actualiza.

Nu utilizați trusted=yes, allow-insecure=yes, --allow-unauthenticated, sau opțiuni similare ca soluție permanentă. Verificarea semnăturii APT verifică dacă metadatele depozitului sunt semnate de o cheie în care ați ales să aveți încredere; dezactivarea acesteia înseamnă că APT nu mai poate oferi acea verificare a integrității. Manualul de securitate APT explică lanțul de autentificare a arhivei și limitele acestuia. Dacă editorul a retras un depozit, a oprit semnarea metadatelor sau nu furnizează o amprentă a cheii verificabilă, eliminați sau dezactivați sursa respectivă în loc să ocoliți verificarea.

Documentația a fost verificată pe 6 octombrie 2026. Formatele depozitului Ubuntu și recomandările privind gestionarea cheilor pot varia în funcție de versiune; utilizați documentația versiunii Ubuntu instalate și instrucțiunile actuale ale editorului depozitului.