Usasishaji wa apt unashindikana na NO_PUBKEY baada ya kuongeza hazina ya VPN

Chanzo cha apt cha mchuuzi wako wa VPN kimevunja msimamizi wa vifurushi, na suluhisho ni uamuzi, si amri. NO_PUBKEY, au malalamiko kwamba hazina haina faili la Release, inamaanisha apt ilikataa kuamini chanzo hicho, kwa hivyo kila operesheni ya vifurushi inayofuata inaendelea kuchapisha onyo lile lile. Handaki yenyewe ina uwezekano wa kuwa haina hatia. Jibu maswali matatu kuhusu ikiwa bado unataka chanzo hicho, na ukarabati sahihi unafuata karibu kimitambo.

Kwanza, weka hitilafu katika kundi sahihi

Hitilafu ya uaminifu hutaja faili la chanzo na ama ufunguo unaokosekana au faili la Release lisilopo. Hitilafu ya usafirishaji inaonekana tofauti: makosa ya cheti cha TLS, muunganisho uliokataliwa, muda kuisha, au proksi inayokataa CONNECT. Tofauti hiyo huamua makala gani unayo soma, kwa sababu VPN inayonasa TLS au inayozuia mwenyeji wa mchuuzi huzalisha hitilafu za usafirishaji, si hitilafu za sahihi.

Endesha sudo apt update peke yake na soma mwisho, ukizipuuza matokeo yaliyohifadhiwa juu. Mstari wa muhimu hutaja /etc/apt/sources.list.d/ na kukuambia faili gani la kufungua.

Ikiwa hitilafu inafuata handaki kupanda, jaribu handaki ikiwa chini na DNS ikitatuliwa na kitatuzi cha mfumo. Chanzo kinachofanya kazi bila VPN ni suala la uelekezaji au unasi, na hakuna kiasi cha usimamizi wa funguo kitakachoirekebisha.

Maswali matatu yanayochagua njia

Bado unasakinisha au unasasisha vifurushi kutoka chanzo hiki? Ikiwa mteja anatumika kwa bidii, rekebisha uaminifu. Ikiwa ulisakinisha mteja mara moja na sasa unaingiza wasifu wa kawaida katika NetworkManager, chanzo ni mzigo usio na maana na kuondoa ni ukarabati wa uaminifu.

Pili, mchuuzi huchapisha ufunguo na alama ya kidole ambayo unaweza kuithibitisha nje ya kituo? Tatu, nani anasimamia funguo kwenye mwenyeji huyu: usambazaji au wewe? Chanzo kilichosainiwa na ufunguo ambao hauwezi kuuthibitisha ni mamlaka ya usasishaji ambayo hupaswi kutoa.

Jibu hapana kwa swali la kwanza linamaliza uchanganuzi. Jibu ndiyo kwa pointi zote tatu linaelekeza kwenye ukarabati wa signed-by, mpangilio pekee unaofanya kazi na kubaki unaoweza kukaguliwa. Kuchanganya njia mbili, kwa kubakiza chanzo na kuilazimisha ipite, ni chaguo pekee linalostahili kutengwa waziwazi.

Kwa nini trusted=yes inaonekana kama ukarabati na haiko

Ukurasa wa mwongozo wa sources.list uko wazi kuhusu hilo. Kuweka chaguo Trusted kuwa yes humwambia apt kukubali chanzo hata kinaposhindwa uthibitishaji, jambo ambalo huzima apt-secure kwa hazina hiyo. Ukurasa unaweka hilo kwa muktadha wa ndani, ikiwa unatumika kabisa.

Hii si toleo jembamba la kumwamini mchuuzi. Inaondoa swali la nani alisaini faharasa, kwa hivyo mtu yeyote anayeweza kujibu kwa jina hilo la mwenyeji anaweza kuipatia mashine yako vifurushi vinavyosakinishwa kama root.

Njia ya ukarabati: chukua ufunguo, kisha ubandike

Chukua ufunguo kutoka mahali mchuuzi anapoandika na uufungue kwenye pete ya funguo inayosimamiwa na msimamizi, kisha uelekeze mstari wa hazina kwenye faili hilo ili uaminifu usiteleze.

1. Soma mstari unaoshindikana kupata ID ya ufunguo na jina la faili la chanzo.
2. Pakua ufunguo wa mchuuzi uliofungwa kwa ASCII na endesha gpg --dearmor kwenda /etc/apt/keyrings/vendor-name.gpg.
3. Ongeza [signed-by=/etc/apt/keyrings/vendor-name.gpg] kwenye ingizo katika faili .list la mchuuzi huyo.
4. Endesha sudo apt update na uthibitishe kwamba chanzo kinapata faharasa badala ya kurudia onyo la sahihi.

Pendelea /usr/share/keyrings kwa funguo zinazokuja na kifurushi na /etc/apt/keyrings kwa funguo unazoweka kwa mkono. Mgawanyiko huu si wa mapambo: unamwambia msimamizi anayefuata funguo gani zitastahimili usasishaji wa kifurushi na zipi zinahitaji mtu.

Thibitisha alama ya kidole dhidi ya thamani iliyochapishwa na mchuuzi kabla ya kuiamini. ID ya ufunguo iliyobandikwa kutoka chapisho la jukwaa ndiyo njia ambayo mashine huanza kuamini mamlaka ya usasishaji ambayo hakuna anayeweza kuitaja.

Njia ya kuondoa, na kwa nini hitilafu inaweza kurudi

Angalia kile kisanikishi kiliandika kweli, kwa sababu faili kadhaa zinaweza kutaja mchuuzi yule yule na moja yao kwa kawaida ni nakala iliyobaki.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt husoma tu .list na .sources faili kutoka saraka hiyo, kwa hivyo nakala ya .save au .distUpgrade tayari inapuuzwa; kuifuta hata hivyo huzuia msomaji wa baadaye kuirejesha kwa bahati mbaya. Kuondoa chanzo hakuondoshi kitu chochote, na apt inaweza kuelezea kifurushi cha VPN kilichosakinishwa kama kimesakinishwa ndani au hakipatikani tena, ambayo ni ujumbe wa hali ya kifurushi na si kurudi kwa hitilafu ya uaminifu.

Kesi inayojirudia ni mwongozo wa zamani uliosakinisha funguo kwa apt-key kwenye pete ya uaminifu ya kimataifa. Njia hiyo imepitwa na wakati, na usasishaji wa toleo unaweza kuacha ufunguo umedondoshwa au usiojulikana kabisa, na ndiyo sababu hitilafu iliyokuwa kimya kwa mwaka inaonekana wiki unaposasisha. Angalia /etc/apt/trusted.gpg.d/, kisha hamishia uamuzi wa uaminifu kwenye mstari wa hazina unapostahili. Ikiwa mchuuzi bado anachapisha maagizo ya apt-key, tumia signed-by hata hivyo; ni mpangilio unaoandikwa na mwongozo, na ndio unaostahimili usasishaji.