HTTPS och ett VPN autentiserar inte paketet du installerar

En uppdatering misslyckas, och förslaget i tråden följer en bekant linje: trafiken går genom ett VPN, så nedladdningen måste vara pålitlig, och signaturkontrollen luckras upp för att komma förbi felet. Två separata idéer har smält samman till en mening. Kryptering skyddar en väg mellan ändpunkter; autentisering avgör om byten kom från utgivaren du menade. En tunnel ger det första och säger ingenting om det andra.

Symtomet är oftast ett verifieringsfel på en värd, i ett arkiv, medan allt annat uppdateras normalt. Den formen säger redan att nätverksvägen fungerar och att oenigheten handlar om tillit.

Två kontroller som svarar på olika frågor

Transportskydd svarar på vem som finns i andra änden av den här anslutningen och om någon på vägen kan läsa eller ändra den. Paketautentisering svarar på om den här artefakten publicerades av den myndighet du konfigurerade, och den måste överleva en nedladdning via en spegel du inte kontrollerar.

De frågorna överlappar bara i kanterna. Ett korrekt certifikat på en spegel bevisar att spegeln är spegeln; det bevisar inte att spegeln innehåller oförändrat utgivarinnehåll. Ett signerat paket bevisar att utgivaren signerade det; det säger inte att nätet levererade den nyaste versionen eller att arkivet du pekade på är det din organisation godkände.

Det felläge folk skapar genom att stänga av kontroller är en permanent förlust av den andra garantin, i utbyte mot en lyckad nedladdning. Den affären är osynlig till den dag den spelar roll.

Vad apt faktiskt autentiserar

APT:s modell är en autentiserad arkivkedja. Signerade utgivningsmetadata leder via kontrollsumma till paketindexen, och de indexen leder via kontrollsumma till de enskilda paketfilerna. Det är verifieringen av kedjan som gör en spegel opålitlig men användbar: spegeln kan servera vad den vill, och signaturen på metadata avgör om APT accepterar det.

Det är med avsikt inte samma sak som att kontrollera en underhållares signatur på varje installerat paket, och skillnaden förklarar varför «paketet är signerat» och «arkivet är autentiserat» används omväxlande i felrapporter när de betyder olika saker.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

Läs utdata från uppdateringen, inte bara utgångskoden. APT namnger arkivet vars metadata misslyckades, och det namnet är gränsen att undersöka. Ett arkiv markerat som betrott utan signaturverifiering, eller en överstyrning för ett osäkert arkiv, är ett konfigurationsbeslut som någon fattat och borde kunna förklara.

Färskhet är återigen en egen egenskap. En giltigt signerad metadatafil kan vara äldre än den du såg förra veckan, därför bär utgivningsmetadata ett utgångsdatum och därför kan ett klockproblem på klienten ge verifieringsfel som ser ut som nyckelproblem.

Vad dnf5 kontrollerar separat

RPM-sidan exponerar två olika brytare, och att blanda ihop dem ger samma felklass i motsatt riktning. Den ena styr om paketfiler måste bära en giltig signatur; den andra om arkivmetadata måste vara signerade. De kan ställas in oberoende, och ett system kan vara strängt på den ena och eftergivet på den andra.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

Paketfrågan visar hur den installerade kopians signaturmetadata ser ut, vilket är en användbar verklighetskontroll mot en konfigurationsfil som hävdar stränghet. Det den inte säger är distributionens stödda policy, och det är den du bör följa i stället för en allmän «aktivera GPG»-instruktion från ett forum.

Där de två hanterarna skiljer sig är skillnaden arkitektonisk och inte ett tecken på att den ena är svagare. Båda autentiserar utgivarinnehåll; de placerar signaturen på olika punkter i kedjan.

Vad tunneln tillför och vad den inte tillför

Ett VPN kan tillhandahålla en nödvändig rutt, hålla uppdateringstrafik utanför ett opålitligt åtkomstnät och minska vad en lokal observatör ser. Det är verkliga driftsfördelar, och ingen av dem är utgivarautentisering.

HTTPS tillför sin egen garanti, och den är smalare än den känns. Den autentiserar den TLS-ändpunkt du anslöt till. Om den ändpunkten är en spegel har du autentiserat spegeln, inte det arkivinnehåll den serverar. Det är just det fall som kedjan av signerade metadata finns för.

Ingen av kontrollerna lovar tillgänglighet. Ett nät kan neka leverans, och ett autentiserat objekt är inte automatiskt det nyaste. Använd pakethanterarens egen färskhetspolicy i stället för att sluta dig till den från förekomsten av ett hänglås.

Diagnostisera gränsen som misslyckades

Namnge steget innan du ändrar något: DNS-uppslagning, proxyn eller rutten, TLS-ändpunktens identitet, arkivautentisering, paketsignaturkontroller eller installation. Varje har en egen felform och en egen ägare.

Reparation av en nätverksväg bör aldrig innebära att förklara en okänd signeringsnyckel betrodd, ignorera certifikat eller acceptera en arkivkonfiguration du inte bad om. Om en nyckel verkligen har roterats publicerar distributionen eller arkivägaren den nya nyckeln via en kanal du kan verifiera, och det är rättelsen som ska tillämpas.

Skriv ned vilken gräns som misslyckades och vem som äger den. Nästa uppdateringsfel kommer att vara vid en annan gräns, och att ha listan gör det till en femminutersdiagnos i stället för ännu en diskussion om huruvida tunneln gör uppdateringar säkra.