Hindi pinapatunayan ng HTTPS at VPN ang paketeng ini-install mo

Nabigo ang isang update, at ang mungkahi sa thread ay sumusunod sa pamilyar na linya: dumadaan ang trapiko sa VPN, kaya dapat mapagkakatiwalaan ang download, at hinuhuwag ang pagsusuri ng pirma para malampasan ang error. Dalawang magkaibang ideya ang pinagsama sa isang pangungusap. Pinoprotektahan ng encryption ang isang landas sa pagitan ng dalawang dulo; ipinapasya ng pagpapatunay kung ang mga byte ay galing sa publisher na nilayon mo. Ang tunnel ay nagbibigay ng una at walang sinasabi tungkol sa pangalawa.

Ang sintomas ay karaniwang error sa beripikasyon sa isang host, sa isang repository, habang normal na nag-a-update ang lahat ng iba. Sinasabi na ng hubog na iyon na gumagana ang landas ng network at tungkol sa tiwala ang hindi pagkakasundo.

Dalawang kontrol na sumasagot sa magkaibang tanong

Ang seguridad ng transportasyon ay sumasagot kung sino ang nasa kabilang dulo ng koneksyong ito at kung may makakabasa o makakabago nito sa landas. Ang pagpapatunay ng pakete ay sumasagot kung ang artefaktong ito ay inilathala ng awtoridad na inayos mo, at kailangan nitong mabuhay sa download sa pamamagitan ng salamin na hindi mo kontrolado.

Nagsasapaw lamang ang mga tanong na iyon sa mga gilid. Ang tamang sertipiko sa isang salamin ay nagpapatunay na ang salamin ay ang salamin; hindi nito pinapatunay na may hindi nabagong nilalaman ng publisher ang salamin. Ang pinirmahang pakete ay nagpapatunay na pinirmahan ito ng publisher; hindi nito sinasabi na inihatid ng network ang pinakabagong bersyon o na ang repository na itinuro mo ay ang inaprubahan ng organisasyon mo.

Ang mode ng pagpalya na nililikha ng mga tao sa pamamagitan ng pagpatay ng mga pagsusuri ay permanenteng pagkawala ng pangalawang garantiya, kapalit ng isang matagumpay na download. Hindi nakikita ang palitang iyon hanggang sa araw na mahalaga ito.

Ano ang talagang pinapatunayan ng apt

Ang modelo ng APT ay isang pinatunayang kadena ng arkibo. Ang mga pinirmahang metadata ng release ay tumutungo sa pamamagitan ng checksum sa mga indeks ng pakete, at ang mga indeks na iyon ay tumutungo sa pamamagitan ng checksum sa mga indibidwal na file ng pakete. Ang beripikasyon ng kadena ang gumagawa sa isang salamin na hindi mapagkakatiwalaan ngunit magagamit: makapaglilingkod ang salamin ng kahit ano, at ang pirma ng metadata ang nagpapasya kung tatanggapin ito ng APT.

Sadyang hindi ito katulad ng pagsuri ng pirma ng maintainer sa bawat naka-install na pakete, at ipinapaliwanag ng pagkakaibang ito kung bakit «ang pakete ay pinirmahan» at «ang arkibo ay pinatunayan» ay ginagamit nang palitan sa mga ulat ng bug kahit magkaiba ang ibig sabihin.

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

Basahin ang output ng update, hindi lamang ang exit code. Pinapangalanan ng APT ang repository na nabigo ang metadata, at ang pangalang iyon ang hangganang dapat imbestigahan. Ang repository na minarkahang mapagkakatiwalaan nang walang beripikasyon ng pirma, o isang override para sa hindi ligtas na repository, ay desisyon sa konfigurasyon na ginawa ng isang tao at dapat niyang maipaliwanag.

Ang kasariwaan ay hiwalay na katangian muli. Ang wastong pinirmahang file ng metadata ay maaaring mas luma kaysa sa nakita mo noong nakaraang linggo, kaya may petsa ng pag-expire ang metadata ng release at kaya ang problema sa orasan sa kliyente ay makakalikha ng mga error sa beripikasyon na mukhang problema sa susi.

Ano ang hiwalay na sinusuri ng dnf5

Ang panig ng RPM ay naglalabas ng dalawang magkaibang switch, at ang paghahalo sa kanila ay lumilikha ng parehong klase ng pagkakamali sa kabilang direksyon. Kinokontrol ng isa kung ang mga file ng pakete ay dapat may wastong pirma; kinokontrol ng isa pa kung ang metadata ng repository ay dapat pinirmahan. Maaari silang itakda nang hiwalay, at ang isang sistema ay maaaring mahigpit sa isa at maluwag sa isa pa.

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

Ipinapakita ng query ng pakete kung ano ang hitsura ng metadata ng pirma ng naka-install na kopya, na kapaki-pakinabang na pagsusuri ng realidad laban sa file ng konfigurasyon na nagsasabing mahigpit ito. Ang hindi nito sinasabi ay ang sinusuportahang patakaran ng distribusyon, at iyon ang dapat mong sundin sa halip na pangkalahatang tagubilin na «i-enable ang GPG» mula sa forum.

Kung saan nagkaiba ang dalawang manager, ang pagkakaiba ay arkitektural at hindi senyales na mas mahina ang isa. Pareho nilang pinapatunayan ang nilalaman ng publisher; inilalagay nila ang pirma sa magkaibang punto sa kadena.

Ano ang idinadagdag ng tunnel at ano ang hindi

Ang VPN ay makapagbibigay ng kinakailangang ruta, makapagpapanatili ng trapiko ng update sa labas ng hindi mapagkakatiwalaang network ng access, at makapagpapababa ng nakikita ng lokal na tagamasid. Tunay na mga benepisyong pang-operasyon ang mga ito, at wala sa mga ito ang pagpapatunay ng publisher.

Nagdadagdag ang HTTPS ng sarili nitong garantiya, at ito ay mas makitid kaysa sa pakiramdam. Pinapatunayan nito ang dulo ng TLS na kinonektahan mo. Kung ang dulong iyon ay salamin, pinatunayan mo ang salamin, hindi ang nilalaman ng arkibo na inihahatid nito. Ito mismo ang kaso na nilikhaan ng kadena ng pinirmahang metadata.

Wala sa dalawang kontrol ang nangangako ng pagiging available. Maaaring tumanggi ang network na maghatid, at ang pinatunayang bagay ay hindi awtomatikong pinakabago. Gamitin ang patakaran ng kasariwaan ng manager ng pakete mismo sa halip na hulaan ito mula sa pagkakaroon ng icon ng kandado.

Diagnosisin ang hangganang nabigo

Pangalanan ang yugto bago magbago ng anuman: resolusyon ng DNS, ang proxy o ruta, pagkakakilanlan ng dulo ng TLS, pagpapatunay ng arkibo, mga pagsusuri ng pirma ng pakete, o pag-install. Bawat isa ay may sariling hubog ng error at sariling may-ari.

Ang pag-aayos ng landas ng network ay hindi dapat kailanman magsama ng pagpapahayag na mapagkakatiwalaan ang isang hindi kilalang susi ng pirma, pagwawalang-bahala sa mga sertipiko, o pagtanggap ng konfigurasyon ng repository na hindi mo hiniling. Kung tunay na naikot ang isang susi, inilalathala ng distribusyon o ng may-ari ng repository ang bagong susi sa pamamagitan ng channel na maaari mong beripikahin, at iyon ang pagwawastong dapat ilapat.

Isulat kung aling hangganan ang nabigo at sino ang may-ari nito. Ang susunod na pagkabigo ng update ay sa ibang hangganan, at ang pagkakaroon ng listahan ay ginagawa itong limang minutong diagnosis sa halip na isa pang pagtatalo kung ginagawang ligtas ng tunnel ang mga update.