HTTPS a VPN neověřují balíček, který instalujete

Aktualizace selže a návrh ve vlákně jde známou linií: provoz jde přes VPN, takže stahování musí být důvěryhodné, a kontrola podpisu se povolí, aby se chyba obešla. Dvě oddělené myšlenky se slily do jedné věty. Šifrování chrání cestu mezi koncovými body; ověření pravosti rozhoduje, zda bajty přišly od vydavatele, kterého jste měli na mysli. Tunel dává první a o druhém neříká nic.

Příznakem bývá chyba ověření na jednom hostiteli, v jednom úložišti, zatímco všechno ostatní se aktualizuje normálně. Tento tvar už říká, že síťová cesta funguje a že spor je o důvěře.

Dvě kontroly, které odpovídají na různé otázky

Zabezpečení přenosu odpovídá, kdo je na druhém konci tohoto spojení a zda ho někdo na cestě může číst nebo měnit. Ověření balíčku odpovídá, zda tento artefakt vydala autorita, kterou jste nastavili, a musí přežít stažení přes zrcadlo, které neovládáte.

Tyto otázky se překrývají jen na okrajích. Správný certifikát na zrcadle dokazuje, že zrcadlo je zrcadlo; nedokazuje, že zrcadlo drží nezměněný obsah vydavatele. Podepsaný balíček dokazuje, že jej vydavatel podepsal; neříká vám, že síť doručila nejnovější verzi nebo že úložiště, na které jste ukázali, je to, které vaše organizace schválila.

Režim selhání, který lidé vytvářejí vypnutím kontrol, je trvalá ztráta druhé záruky výměnou za jedno úspěšné stažení. Tato výměna je neviditelná až do dne, kdy na ní záleží.

Co apt skutečně ověřuje

Model APT je řetěz ověřeného archivu. Podepsaná metadata vydání vedou přes kontrolní součet k indexům balíčků a tyto indexy vedou přes kontrolní součet k jednotlivým souborům balíčků. Právě ověření řetězu dělá zrcadlo nedůvěryhodným, ale použitelným: zrcadlo může posloužit cokoli chce a podpis metadat rozhoduje, zda to APT přijme.

To záměrně není totéž jako kontrola podpisu správce u každého nainstalovaného balíčku a tento rozdíl vysvětluje, proč se v hlášeních chyb „balíček je podepsaný“ a „archiv je ověřený“ používají zaměnitelně, i když znamenají různé věci.

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

Čtěte výstup aktualizace, ne jen návratový kód. APT pojmenuje úložiště, jehož metadata selhala, a to jméno je hranice k vyšetření. Úložiště označené jako důvěryhodné bez ověření podpisu nebo přepis pro nezabezpečené úložiště je konfigurační rozhodnutí, které někdo udělal a měl by je umět vysvětlit.

Čerstvost je opět samostatná vlastnost. Platně podepsaný soubor metadat může být starší než ten, který jste viděli minulý týden, proto metadata vydání nesou expiraci a proto problém s hodinami na klientovi může způsobit chyby ověření, které vypadají jako problémy s klíčem.

Co dnf5 kontroluje odděleně

Strana RPM nabízí dva odlišné přepínače a jejich záměna dává stejnou třídu chyby v opačném směru. Jeden řídí, zda soubory balíčků musí nést platný podpis; druhý řídí, zda metadata úložiště musí být podepsaná. Lze je nastavit nezávisle a systém může být přísný v jednom a benevolentní ve druhém.

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

Dotaz na balíček ukazuje, jak vypadají metadata podpisu nainstalované kopie, což je užitečná kontrola reality proti konfiguračnímu souboru, který tvrdí přísnost. Co vám neřekne, je podporovaná politika distribuce, a právě tu byste měli následovat místo obecného pokynu „zapněte GPG“ z fóra.

Kde se oba správci liší, je rozdíl architektonický, ne znak toho, že jeden je slabší. Oba ověřují obsah vydavatele; podpis umisťují na různá místa řetězu.

Co tunel přidává a co ne

VPN může zajistit požadovanou trasu, udržet provoz aktualizací mimo nedůvěryhodnou přístupovou síť a snížit to, co vidí místní pozorovatel. To jsou skutečné provozní výhody a žádná z nich není ověřením vydavatele.

HTTPS přidává vlastní záruku a ta je užší, než se zdá. Ověřuje koncový bod TLS, ke kterému jste se připojili. Pokud je tím koncovým bodem zrcadlo, ověřili jste zrcadlo, ne obsah archivu, který poskytuje. To je přesně případ, pro který řetěz podepsaných metadat existuje.

Ani jedna kontrola neslibuje dostupnost. Síť může doručení odmítnout a ověřený objekt není automaticky nejnovější. Používejte vlastní politiku čerstvosti správce balíčků, místo abyste ji odvozovali z přítomnosti ikony zámku.

Diagnostikujte hranici, která selhala

Pojmenujte fázi, než cokoli změníte: překlad DNS, proxy nebo trasu, identitu koncového bodu TLS, ověření archivu, kontroly podpisu balíčků nebo instalaci. Každá má odlišný tvar chyby a odlišného vlastníka.

Oprava síťové cesty by nikdy neměla zahrnovat prohlášení neznámého podpisového klíče za důvěryhodný, ignorování certifikátů nebo přijetí konfigurace úložiště, o kterou jste nežádali. Pokud se klíč skutečně vyměnil, distribuce nebo vlastník úložiště zveřejní nový klíč kanálem, který můžete ověřit, a to je oprava, kterou je třeba použít.

Zapište, která hranice selhala a kdo ji vlastní. Příští selhání aktualizace bude na jiné hranici a mít seznam z něj dělá diagnózu na pět minut místo dalšího sporu o tom, zda tunel dělá aktualizace bezpečnými.