HTTPS kaj VPN ne aŭtentigas la pakaĵon, kiun vi instalas

Ĝisdatigo malsukcesas, kaj la propono en la fadeno sekvas konatan linion: la trafiko iras tra VPN, do la elŝuto devas esti fidinda, kaj la subskriba kontrolo malstreĉiĝas por preterpasi la eraron. Du apartaj ideoj kunfandiĝis en unu frazo. Ĉifrado protektas vojon inter finpunktoj; aŭtentigo decidas ĉu la bajtoj venis de la eldoninto, kiun vi celis. Tunelo liveras la unuan kaj diras nenion pri la dua.

La simptomo kutime estas kontroleraro sur unu gastiganto, en unu deponejo, dum ĉio alia ĝisdatiĝas normale. Tiu formo jam diras, ke la reta vojo funkcias kaj ke la malkonsento temas pri fido.

Du kontroloj, kiuj respondas malsamajn demandojn

Transporta sekureco respondas, kiu estas ĉe la alia fino de ĉi tiu konekto kaj ĉu iu sur la vojo povas legi aŭ ŝanĝi ĝin. Pakaĵa aŭtentigo respondas, ĉu ĉi tiun artefakton publikigis la aŭtoritato, kiun vi agordis, kaj ĝi devas postvivi elŝuton tra spegulo, kiun vi ne kontrolas.

Tiuj demandoj interkovras nur ĉe la randoj. Ĝusta atestilo sur spegulo pruvas, ke la spegulo estas la spegulo; ĝi ne pruvas, ke la spegulo tenas neŝanĝitan eldonintan enhavon. Subskribita pakaĵo pruvas, ke la eldoninto subskribis ĝin; ĝi ne diras al vi, ke la reto liveris la plej novan version aŭ ke la deponejo, kiun vi indikis, estas tiu, kiun via organizo aprobis.

La malsukcesa modo, kiun homoj kreas per malŝalto de kontroloj, estas daŭra perdo de la dua garantio kontraŭ unu sukcesa elŝuto. Tiu interŝanĝo estas nevidebla ĝis la tago, kiam ĝi gravas.

Kion apt efektive aŭtentigas

La modelo de APT estas aŭtentigita arkiva ĉeno. Subskribitaj eldonaj metadatumoj kondukas per kontrolsumo al la pakaĵaj indeksoj, kaj tiuj indeksoj kondukas per kontrolsumo al la unuopaj pakaĵaj dosieroj. La kontrolo de la ĉeno estas tio, kio faras spegulon nefidinda sed uzebla: la spegulo povas servi kion ajn ĝi volas, kaj la subskribo de la metadatumoj decidas, ĉu APT akceptas ĝin.

Tio intence ne estas la sama kiel kontroli subskribon de prizorganto sur ĉiu instalita pakaĵo, kaj la distingo klarigas, kial «la pakaĵo estas subskribita» kaj «la arkivo estas aŭtentigita» estas uzataj interŝanĝe en erar-raportoj, kvankam ili signifas malsamajn aferojn.

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

Legu la eligon de la ĝisdatigo, ne nur la eligan kodon. APT nomas la deponejon, kies metadatumoj malsukcesis, kaj tiu nomo estas la limo por esplori. Deponejo markita kiel fidinda sen subskriba kontrolo, aŭ trudado por nesekura deponejo, estas agorda decido, kiun iu faris kaj devus povi klarigi.

Freŝeco estas denove aparta eco. Valide subskribita metadatumdosiero povas esti pli malnova ol tiu, kiun vi vidis pasintsemajne, tial eldonaj metadatumoj portas limdaton kaj tial horloĝa problemo sur la kliento povas produkti kontrolerarojn, kiuj aspektas kiel ŝlosilaj problemoj.

Kion dnf5 kontrolas aparte

La RPM-flanko elmontras du apartajn ŝaltilojn, kaj ilin konfuzi produktas la saman klason de eraro en la alia direkto. Unu regas, ĉu pakaĵaj dosieroj devas porti validan subskribon; la alia regas, ĉu deponejaj metadatumoj devas esti subskribitaj. Ili povas esti agorditaj sendepende, kaj sistemo povas esti severa pri unu kaj cedema pri la alia.

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

La pakaĵa demando montras, kiel aspektas la subskribaj metadatumoj de la instalita kopio, kio estas utila realec-kontrolo kontraŭ agorda dosiero, kiu asertas severecon. Kion ĝi ne diras al vi, estas la subtenata politiko de la distribuo, kaj ĝin vi devus sekvi anstataŭ ĝenerala instrukcio «ŝaltu GPG» el forumo.

Kie la du administriloj malsamas, la diferenco estas arkitektura, ne signo ke unu estas pli malforta. Ambaŭ aŭtentigas eldonintan enhavon; ili metas la subskribon ĉe malsamaj punktoj en la ĉeno.

Kion la tunelo aldonas kaj kion ne

VPN povas liveri bezonatan vojon, teni ĝisdatigan trafikon ekster nefidinda alira reto kaj malpliigi tion, kion vidas loka observanto. Tiuj estas realaj operaciaj avantaĝoj, kaj neniu el ili estas eldoninta aŭtentigo.

HTTPS aldonas sian propran garantion, kaj ĝi estas pli mallarĝa ol ĝi sentiĝas. Ĝi aŭtentigas la TLS-finpunkton, al kiu vi konektiĝis. Se tiu finpunkto estas spegulo, vi aŭtentigis la spegulon, ne la arkivan enhavon, kiun ĝi servas. Ĝuste tiu estas la kazo, por kiu ekzistas la ĉeno de subskribitaj metadatumoj.

Neniu el la kontroloj promesas haveblecon. Reto povas rifuzi liveron, kaj aŭtentigita objekto ne aŭtomate estas la plej nova. Uzu la propran freŝecpolitikon de la pakaĵadministrilo anstataŭ dedukti ĝin el la ĉeesto de serura ikono.

Diagnozu la limon, kiu malsukcesis

Nomu la etapon antaŭ ol ŝanĝi ion: DNS-elrezolvado, la prokurilo aŭ vojo, la identeco de la TLS-finpunkto, arkiva aŭtentigo, pakaĵaj subskribaj kontroloj aŭ instalado. Ĉiu havas apartan eraroformon kaj apartan posedanton.

Ripari retan vojon neniam devus impliki deklari nekonatan subskriban ŝlosilon fidinda, ignori atestilojn aŭ akcepti deponejan agordon, kiun vi ne petis. Se ŝlosilo vere rotaciiĝis, la distribuo aŭ la deponeja posedanto publikigas la novan ŝlosilon per kanalo, kiun vi povas kontroli, kaj tio estas la korekto aplikenda.

Skribu, kiu limo malsukcesis kaj kiu posedas ĝin. La sekva ĝisdatiga malsukceso okazos ĉe alia limo, kaj havi la liston faras ĝin kvinminuta diagnozo anstataŭ plia argumento pri tio, ĉu la tunelo igas ĝisdatigojn sekuraj.