apt-opdatering fejler med NO_PUBKEY efter tilføjelse af et VPN-lager

Din VPN-leverandørs apt-kilde har ødelagt din pakkehåndtering, og rettelsen er en beslutning, ikke en kommando. NO_PUBKEY, eller en klage over at lageret ikke har nogen Release-fil, betyder, at apt har afvist at stole på den kilde, så enhver senere pakkehandling bliver ved med at udskrive den samme advarsel. Selve tunnelen er sandsynligvis uskyldig. Besvar tre spørgsmål om, hvorvidt du stadig vil have den kilde, og den korrekte reparation følger næsten mekanisk.

Først: anbring fejlen i den rigtige kategori

En tillidsfejl nævner kildefilen og enten den manglende nøgle eller den fraværende Release-fil. En transportfejl ser anderledes ud: TLS-certifikatfejl, forbindelse nægtet, tidsudløb eller en proxy, der nægter CONNECT. Den forskel afgør, hvilken artikel du læser, fordi en VPN, der opfanger TLS eller blokerer leverandørens vært, giver transportfejl, ikke signaturfejl.

Kør sudo apt update alene og læs slutningen, mens du ignorerer de cachelagrede hits ovenover. Den linje, der betyder noget, nævner /etc/apt/sources.list.d/ og fortæller dig, hvilken fil du skal åbne.

Hvis fejlen følger, når tunnelen kommer op, så test med tunnelen nede og med DNS slået op via systemets resolver. En kilde, der virker uden VPN'en, er et routing- eller opfangningsspørgsmål, og ingen mængde nøglestyring retter det.

Tre spørgsmål, der vælger vejen

Installerer eller opgraderer du stadig pakker fra denne kilde? Hvis klienten er i aktiv brug, så reparér tilliden. Hvis du installerede klienten én gang og nu importerer en almindelig profil i NetworkManager, er kilden død vægt, og fjernelse er den ærlige rettelse.

For det andet: offentliggør leverandøren en nøgle og et fingeraftryk, som du kan verificere uden for kanalen? For det tredje: hvem styrer nøgler på denne vært, distributionen eller dig? En kilde signeret med en nøgle, du ikke kan verificere, er en opdateringsmyndighed, du ikke bør give.

Et nej til det første spørgsmål afslutter analysen. Et ja til alle tre peger på signed-by-reparationen, som er den eneste ordning, der både virker og forbliver reviderbar. At blande de to veje ved at beholde kilden og tvinge den igennem er den ene mulighed, der er værd at udelukke eksplicit.

Hvorfor trusted=yes ligner en rettelse og ikke er det

Siden i manualen for sources.list er direkte om det. At sætte indstillingen Trusted til yes fortæller apt at acceptere kilden, selv når den ikke består godkendelse, hvilket slår apt-secure fra for det lager. Siden forbeholder det til en lokal sammenhæng, hvis det overhovedet bruges.

Det er ikke en snævrere version af at stole på leverandøren. Det fjerner spørgsmålet om, hvem der signerede indekset, så enhver, der kan svare for det værtsnavn, kan give din maskine pakker, der installeres som root.

Reparationsvej: hent nøglen, og fastgør den så

Hent nøglen fra det sted, leverandøren dokumenterer, og afpansr den ind i en nøglering, som administratoren styrer, og peg derefter lagerlinjen på den fil, så tilliden ikke kan drive.

1. Læs den fejlende linje for at få nøgle-ID'et og kildefilens navn.
2. Download leverandørens ASCII-pansrede nøgle, og kør gpg --dearmor ind i /etc/apt/keyrings/vendor-name.gpg.
3. Tilføj [signed-by=/etc/apt/keyrings/vendor-name.gpg] til posten i den leverandørs .list-fil.
4. Kør sudo apt update og bekræft, at kilden henter et indeks i stedet for at gentage signaturadvarslen.

Foretræk /usr/share/keyrings til nøgler, der kommer med en pakke, og /etc/apt/keyrings til nøgler, du selv placerer. Opdelingen er ikke kosmetisk: den fortæller den næste administrator, hvilke nøgler der overlever en pakkeopgradering, og hvilke der kræver et menneske.

Verificér fingeraftrykket mod leverandørens offentliggjorte værdi, før du stoler på det. Et nøgle-ID kopieret fra et forumindlæg er, hvordan en maskine ender med at stole på en opdateringsmyndighed, som ingen kan navngive.

Fjernelsesvej, og hvorfor fejlen kan komme tilbage

Se på, hvad installationsprogrammet faktisk skrev, fordi flere filer kan nævne den samme leverandør, og en af dem er normalt en restkopi.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt læser kun .list og .sources-filer fra den mappe, så en .save eller .distUpgrade-kopi ignoreres allerede; at slette den alligevel forhindrer en senere læser i at gendanne den ved et uheld. At fjerne kilden afinstallerer intet, og apt kan derefter beskrive den installerede VPN-pakke som lokalt installeret eller ikke længere tilgængelig, hvilket er en pakketilstandsmeddelelse og ikke tillidsfejlen, der vender tilbage.

Det tilbagevendende tilfælde er ældre vejledning, der installerede nøgler med apt-key i den globale betroede ring. Den vej er forældet, og en udgivelsesopgradering kan efterlade nøglen droppet eller simpelthen ukonsulteret, og det er netop derfor, en fejl, der var stille i et år, dukker op i den uge, du opgraderer. Tjek /etc/apt/trusted.gpg.d/, og flyt derefter tillidsbeslutningen ind i lagerlinjen, hvor den hører hjemme. Hvis leverandøren stadig udskriver apt-key-instruktioner, så brug signed-by alligevel; det er den ordning, manualen dokumenterer, og den, der overlever en opgradering.