HTTPS și un VPN nu autentifică pachetul pe care îl instalezi

Un update eșuează, iar sugestia din fir urmează o linie cunoscută: traficul trece printr-un VPN, deci descărcarea trebuie să fie de încredere, iar verificarea semnăturii este relaxată ca să treacă de eroare. Două idei separate au fost contopite într-o singură propoziție. Criptarea protejează o cale între capete; autentificarea decide dacă octeții au venit de la editorul la care te-ai gândit. Un tunel oferă prima și nu spune nimic despre a doua.

Simptomul este de obicei o eroare de verificare pe un singur host, într-un singur depozit, în timp ce tot restul se actualizează normal. Acea formă spune deja că traseul de rețea funcționează și că neînțelegerea este despre încredere.

Două controale care răspund la întrebări diferite

Securitatea transportului răspunde cine se află la celălalt capăt al acestei conexiuni și dacă cineva de pe traseu o poate citi sau modifica. Autentificarea pachetului răspunde dacă acest artefact a fost publicat de autoritatea pe care ai configurat-o și trebuie să supraviețuiască unei descărcări printr-o oglindă pe care nu o controlezi.

Aceste întrebări se suprapun doar la margini. Un certificat corect pe o oglindă dovedește că oglinda este oglinda; nu dovedește că oglinda conține conținut de editor nemodificat. Un pachet semnat dovedește că editorul l-a semnat; nu îți spune că rețeaua a livrat cea mai nouă versiune sau că depozitul pe care l-ai indicat este cel aprobat de organizația ta.

Modul de eșec pe care oamenii îl creează dezactivând verificările este pierderea permanentă a celei de-a doua garanții, în schimbul unei singure descărcări reușite. Acel schimb este invizibil până în ziua în care contează.

Ce autentifică de fapt apt

Modelul APT este un lanț de arhivă autentificat. Metadatele de lansare semnate conduc prin sumă de control la indexurile pachetelor, iar acele indexuri conduc prin sumă de control la fișierele individuale de pachet. Verificarea lanțului este ce face o oglindă neîncrezută, dar utilizabilă: oglinda poate servi orice vrea, iar semnătura metadatelor decide dacă APT o acceptă.

Acest lucru în mod deliberat nu este la fel cu verificarea semnăturii unui întreținător pe fiecare pachet instalat, iar distincția explică de ce «pachetul este semnat» și «arhiva este autentificată» sunt folosite interschimbabil în rapoartele de erori când înseamnă lucruri diferite.

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

Citește ieșirea actualizării, nu doar codul de ieșire. APT numește depozitul ale cărui metadate au eșuat, iar acel nume este granița de investigat. Un depozit marcat ca de încredere fără verificarea semnăturii, sau o suprascriere pentru un depozit nesigur, este o decizie de configurare pe care cineva a luat-o și ar trebui să o poată explica.

Prospețimea este din nou o proprietate separată. Un fișier de metadate semnat valid poate fi mai vechi decât cel pe care l-ai văzut săptămâna trecută, de aceea metadatele de lansare au o dată de expirare și de aceea o problemă de ceas pe client poate produce erori de verificare care arată ca probleme de cheie.

Ce verifică dnf5 separat

Partea RPM expune două comutatoare distincte, iar confundarea lor produce aceeași clasă de eroare în direcția opusă. Unul controlează dacă fișierele de pachet trebuie să poarte o semnătură validă; celălalt dacă metadatele depozitului trebuie să fie semnate. Ele pot fi setate independent, iar un sistem poate fi strict la unul și îngăduitor la celălalt.

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

Interogarea pachetului arată cum arată metadatele de semnătură ale copiei instalate, ceea ce este o verificare de realitate utilă față de un fișier de configurare care pretinde rigoare. Ce nu îți spune este politica acceptată a distribuției, și pe aceea ar trebui să o urmezi în locul unei instrucțiuni generice «activează GPG» de pe un forum.

Acolo unde cei doi manageri diferă, diferența este arhitecturală și nu un semn că unul este mai slab. Ambele autentifică conținutul editorului; ele plasează semnătura în puncte diferite ale lanțului.

Ce adaugă tunelul și ce nu

Un VPN poate oferi o rută necesară, poate ține traficul de actualizare în afara unei rețele de acces nesigure și poate reduce ce vede un observator local. Sunt beneficii operaționale reale, și niciunul dintre ele nu este autentificarea editorului.

HTTPS adaugă propria garanție, iar ea este mai îngustă decât pare. Autentifică capătul TLS la care te-ai conectat. Dacă acel capăt este o oglindă, ai autentificat oglinda, nu conținutul arhivei pe care îl servește. Acesta este exact cazul pentru care există lanțul de metadate semnate.

Niciunul dintre controale nu promite disponibilitate. O rețea poate refuza livrarea, iar un obiect autentificat nu este automat cel mai nou. Folosește politica de prospețime a managerului de pachete însuși în loc să o deduci din prezența unei pictograme de lacăt.

Diagnostichează granița care a eșuat

Numește etapa înainte de a schimba ceva: rezolvarea DNS, proxy-ul sau ruta, identitatea capătului TLS, autentificarea arhivei, verificările semnăturii pachetului sau instalarea. Fiecare are o formă de eroare și un proprietar distincte.

Repararea unei căi de rețea nu ar trebui să implice niciodată declararea unei chei de semnare necunoscute ca fiind de încredere, ignorarea certificatelor sau acceptarea unei configurații de depozit pe care nu ai cerut-o. Dacă o cheie chiar a fost rotită, distribuția sau proprietarul depozitului publică cheia nouă printr-un canal pe care îl poți verifica, și aceasta este corecția de aplicat.

Notează care graniță a eșuat și cine o deține. Următorul eșec de actualizare va fi la altă graniță, iar a avea lista îl face un diagnostic de cinci minute în loc de încă o dezbatere despre dacă tunelul face actualizările sigure.