HTTPS un VPN neautentificē pakotni, ko jūs instalējat

Atjauninājums neizdodas, un ieteikums pavedienā seko pazīstamai līnijai: trafiks iet caur VPN, tāpēc lejupielādei jābūt uzticamai, un paraksta pārbaude tiek mīkstināta, lai apietu kļūdu. Divas atsevišķas idejas ir sapludinātas vienā teikumā. Šifrēšana aizsargā ceļu starp galapunktiem; autentifikācija izlemj, vai baiti nāca no izdevēja, ko jūs domājāt. Tunelis dod pirmo un neko nepasaka par otro.

Simptoms parasti ir verifikācijas kļūda vienā resursdatorā, vienā krātuvē, kamēr viss pārējais atjaunojas normāli. Šī forma jau pasaka, ka tīkla ceļš darbojas un ka domstarpības ir par uzticēšanos.

Divas kontroles, kas atbild uz dažādiem jautājumiem

Transporta drošība atbild, kas ir šī savienojuma otrā galā un vai kāds ceļā var to lasīt vai mainīt. Pakotnes autentifikācija atbild, vai šo artefaktu publicēja jūsu konfigurētā iestāde, un tai jāiztur lejupielāde caur spoguli, ko jūs nekontrolējat.

Šie jautājumi pārklājas tikai malās. Pareizs sertifikāts uz spoguļa pierāda, ka spogulis ir spogulis; tas nepierāda, ka spogulī ir nemainīts izdevēja saturs. Parakstīta pakotne pierāda, ka izdevējs to parakstīja; tā nepasaka, ka tīkls piegādāja jaunāko versiju vai ka jūsu norādītā krātuve ir tā, ko apstiprinājusi jūsu organizācija.

Kļūmes režīms, ko cilvēki rada, izslēdzot pārbaudes, ir pastāvīgs otrās garantijas zaudējums apmaiņā pret vienu veiksmīgu lejupielādi. Šī apmaiņa ir neredzama līdz dienai, kad tai ir nozīme.

Ko apt faktiski autentificē

APT modelis ir autentificēta arhīva ķēde. Parakstīti izlaiduma metadati caur kontrolsummu ved pie pakotņu indeksiem, un šie indeksi caur kontrolsummu ved pie atsevišķām pakotnes datnēm. Tieši ķēdes verificēšana padara spoguli neuzticamu, bet lietojamu: spogulis var pasniegt jebko, un metadatu paraksts izlemj, vai APT to pieņems.

Tas apzināti nav tas pats, kas pārraudzītāja paraksta pārbaude katrā instalētajā pakotnē, un šī atšķirība izskaidro, kāpēc kļūdu ziņojumos «pakotne ir parakstīta» un «arhīvs ir autentificēts» tiek lietoti vietām, lai gan tie nozīmē dažādas lietas.

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

Lasiet atjauninājuma izvadi, nevis tikai iziešanas kodu. APT nosauc krātuvi, kuras metadati neizdevās, un šis nosaukums ir izmeklējamā robeža. Krātuve, kas atzīmēta kā uzticama bez paraksta verifikācijas, vai nedrošas krātuves pārrakstīšana, ir kāda pieņemts konfigurācijas lēmums, un viņam tas būtu jāspēj izskaidrot.

Svaigums atkal ir atsevišķa īpašība. Derīgi parakstīta metadatu datne var būt vecāka par to, ko redzējāt pagājušajā nedēļā, tāpēc izlaiduma metadatiem ir derīguma termiņš un tāpēc klienta pulksteņa problēma var radīt verifikācijas kļūdas, kas izskatās kā atslēgu problēmas.

Ko dnf5 pārbauda atsevišķi

RPM puse piedāvā divus atšķirīgus slēdžus, un to sajaukšana rada to pašu kļūdu klasi pretējā virzienā. Viens kontrolē, vai pakotnes datnēm jābūt derīgam parakstam; otrs – vai krātuves metadatiem jābūt parakstītiem. Tos var iestatīt neatkarīgi, un sistēma var būt stingra vienā un iecietīga otrā.

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

Pakotnes vaicājums parāda, kā izskatās instalētās kopijas paraksta metadati, un tas ir noderīga realitātes pārbaude pret konfigurācijas datni, kas apgalvo stingrību. Ko tas nepasaka, ir izplatījuma atbalstītā politika, un tai jums būtu jāseko, nevis vispārīgam «iespējojiet GPG» norādījumam no foruma.

Kur divi pārvaldnieki atšķiras, atšķirība ir arhitektoniska, nevis zīme, ka viens ir vājāks. Abi autentificē izdevēja saturu; tie ievieto parakstu dažādos ķēdes punktos.

Ko tunelis pievieno un ko ne

VPN var nodrošināt nepieciešamo maršrutu, turēt atjauninājumu trafiku ārpus neuzticama piekļuves tīkla un samazināt to, ko redz vietējais novērotājs. Tie ir reāli darbības ieguvumi, un neviens no tiem nav izdevēja autentifikācija.

HTTPS pievieno savu garantiju, un tā ir šaurāka, nekā šķiet. Tas autentificē TLS galapunktu, kuram pievienojāties. Ja šis galapunkts ir spogulis, jūs autentificējāt spoguli, nevis tā pasniegto arhīva saturu. Šis ir tieši tas gadījums, kuram pastāv parakstītu metadatu ķēde.

Neviena no kontrolēm nesola pieejamību. Tīkls var atteikt piegādi, un autentificēts objekts nav automātiski jaunākais. Izmantojiet paša pakotņu pārvaldnieka svaiguma politiku, nevis seciniet to no slēdzenes ikonas klātbūtnes.

Diagnosticējiet robežu, kas neizdevās

Nosauciet posmu, pirms kaut ko maināt: DNS izšķiršana, starpniekserveris vai maršruts, TLS galapunkta identitāte, arhīva autentifikācija, pakotnes paraksta pārbaudes vai instalēšana. Katram ir sava kļūdas forma un savs īpašnieks.

Tīkla ceļa labošana nekad nedrīkst ietvert nezināmas paraksta atslēgas pasludināšanu par uzticamu, sertifikātu ignorēšanu vai tādas krātuves konfigurācijas pieņemšanu, ko jūs neprasījāt. Ja atslēga patiešām ir nomainīta, izplatījums vai krātuves īpašnieks publicē jauno atslēgu kanālā, ko varat verificēt, un tas ir piemērojamais labojums.

Pierakstiet, kura robeža neizdevās un kas par to atbild. Nākamā atjauninājuma kļūme būs citā robežā, un saraksta esamība to pārvērš piecu minūšu diagnozē, nevis vēl vienā strīdā par to, vai tunelis padara atjauninājumus drošus.