HTTPS og en VPN godkender ikke den pakke, du installerer

En opdatering fejler, og forslaget i tråden følger en kendt linje: trafikken går gennem en VPN, så downloadet må være troværdigt, og signaturkontrollen lempes for at komme forbi fejlen. To adskilte idéer er smeltet sammen til én sætning. Kryptering beskytter en vej mellem endepunkter; godkendelse afgør, om bytene kom fra den udgiver, du havde tænkt på. En tunnel giver det første og siger intet om det andet.

Symptomet er normalt en verifikationsfejl på én vært, i ét lager, mens alt andet opdateres normalt. Den form fortæller allerede, at netværksvejen virker, og at uenigheden handler om tillid.

To kontroller, der besvarer forskellige spørgsmål

Transportsikkerhed besvarer, hvem der er i den anden ende af denne forbindelse, og om nogen på vejen kan læse eller ændre den. Pakkegodkendelse besvarer, om denne artefakt blev udgivet af den myndighed, du konfigurerede, og den skal overleve at blive hentet gennem et spejl, du ikke kontrollerer.

De spørgsmål overlapper kun i kanterne. Et korrekt certifikat på et spejl beviser, at spejlet er spejlet; det beviser ikke, at spejlet indeholder uændret udgiverindhold. En signeret pakke beviser, at udgiveren har signeret den; den fortæller dig ikke, at netværket leverede den nyeste version, eller at det lager, du pegede på, er det, din organisation har godkendt.

Den fejltilstand, folk skaber ved at slå kontroller fra, er et permanent tab af den anden garanti til gengæld for ét vellykket download. Den byttehandel er usynlig indtil den dag, den betyder noget.

Hvad apt faktisk godkender

APT’s model er en godkendt arkivkæde. Signerede udgivelsesmetadata fører via kontrolsum til pakkeindeksene, og de indeks fører via kontrolsum til de enkelte pakkefiler. Det er verifikationen af kæden, der gør et spejl utroværdigt, men brugbart: spejlet kan servere, hvad det vil, og metadatasignaturen afgør, om APT accepterer det.

Det er bevidst ikke det samme som at kontrollere en vedligeholders signatur på hver installeret pakke, og forskellen forklarer, hvorfor «pakken er signeret» og «arkivet er godkendt» bruges i flæng i fejlrapporter, når de betyder forskellige ting.

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

Læs opdateringens output i stedet for kun exitkoden. APT navngiver det lager, hvis metadata fejlede, og det navn er grænsen, der skal undersøges. Et lager markeret som betroet uden signaturverifikation, eller en tilsidesættelse for et usikkert lager, er en konfigurationsbeslutning, nogen har taget og bør kunne forklare.

Friskhed er igen en separat egenskab. En gyldigt signeret metadatafil kan være ældre end den, du så i sidste uge, og derfor har udgivelsesmetadata en udløbsdato, og derfor kan et urproblem på klienten give verifikationsfejl, der ligner nøgleproblemer.

Hvad dnf5 kontrollerer separat

RPM-siden eksponerer to forskellige kontakter, og at forveksle dem giver samme slags fejl i den anden retning. Den ene styrer, om pakkefiler skal bære en gyldig signatur; den anden styrer, om lagermetadata skal være signeret. De kan sættes uafhængigt, og et system kan være strengt om det ene og eftergivende om det andet.

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

Pakkeforespørgslen viser, hvordan den installerede kopis signaturmetadata ser ud, hvilket er et nyttigt virkelighedstjek mod en konfigurationsfil, der hævder strenghed. Hvad den ikke fortæller dig, er distributionens understøttede politik, og det er den, du bør følge i stedet for en generisk «aktivér GPG»-instruks fra et forum.

Hvor de to håndteringer adskiller sig, er forskellen arkitektonisk snarere end et tegn på, at den ene er svagere. Begge godkender udgiverindhold; de placerer signaturen forskellige steder i kæden.

Hvad tunnelen tilføjer, og hvad den ikke gør

En VPN kan levere en påkrævet rute, holde opdateringstrafik væk fra et utroværdigt adgangsnetværk og reducere, hvad en lokal observatør ser. Det er reelle driftsfordele, og ingen af dem er udgivergodkendelse.

HTTPS tilføjer sin egen garanti, og den er smallere, end den føles. Den godkender det TLS-endepunkt, du forbinder til. Hvis det endepunkt er et spejl, har du godkendt spejlet, ikke det arkivindhold, det serverer. Det er netop det tilfælde, som kæden af signerede metadata findes til.

Ingen af kontrollerne lover tilgængelighed. Et netværk kan afvise levering, og et godkendt objekt er ikke automatisk det nyeste. Brug pakkehåndterings egen friskhedspolitik i stedet for at udlede den af tilstedeværelsen af et hængelåsikon.

Diagnostiser den grænse, der fejlede

Navngiv trinnet, før du ændrer noget: DNS-opslag, proxyen eller ruten, TLS-endepunktets identitet, arkivgodkendelse, pakkesignaturkontroller eller installation. Hvert har en særlig fejlform og en særlig ejer.

Reparation af en netværksvej bør aldrig indebære at erklære en ukendt signeringsnøgle betroet, ignorere certifikater eller acceptere en lagerkonfiguration, du ikke har bedt om. Hvis en nøgle reelt er roteret, offentliggør distributionen eller lagerejeren den nye nøgle gennem en kanal, du kan verificere, og det er den rettelse, der skal anvendes.

Skriv ned, hvilken grænse der fejlede, og hvem der ejer den. Den næste opdateringsfejl vil være ved en anden grænse, og at have listen gør det til en fem minutters diagnose i stedet for endnu en diskussion om, hvorvidt tunnelen gør opdateringer sikre.