HTTPS र VPN ले तपाईंले स्थापना गर्ने प्याकेज प्रमाणित गर्दैनन्

एउटा अपडेट असफल हुन्छ, र थ्रेडमा सुझाव परिचित बाटोमा जान्छ: ट्राफिक VPN भएर जान्छ, त्यसैले डाउनलोड विश्वसनीय हुनैपर्छ भन्ने ठानेर त्रुटि छल्न हस्ताक्षर जाँच खुकुलो बनाइन्छ। दुई छुट्टै विचार एउटै वाक्यमा मिलाइएका छन्। इन्क्रिप्शनले दुई छेउबीचको बाटो सुरक्षित गर्छ; प्रमाणीकरणले बाइटहरू तपाईंले चिताएको प्रकाशकबाट आए वा नआएको निर्णय गर्छ। सुरुङले पहिलो दिन्छ र दोस्रोबारे केही भन्दैन।

लक्षण सामान्यतया एउटै होस्टमा, एउटै भण्डारमा जाँच त्रुटि हो, जबकि बाँकी सबै सामान्य रूपमा अपडेट हुन्छ। त्यो आकारले नै नेटवर्क मार्ग काम गरिरहेको छ र विवाद विश्वासको बारेमा हो भन्ने बताउँछ।

फरक प्रश्नको जवाफ दिने दुई नियन्त्रण

यातायात सुरक्षाले यो जडानको अर्को छेउमा को छ र मार्गमा कसैले यसलाई पढ्न वा बदल्न सक्छ कि भन्ने जवाफ दिन्छ। प्याकेज प्रमाणीकरणले यो वस्तु तपाईंले कन्फिगर गरेको अधिकारले प्रकाशित गरेको हो कि भन्ने जवाफ दिन्छ, र तपाईंले नियन्त्रण नगर्ने ऐनाबाट डाउनलोड पनि सहनुपर्छ।

ती प्रश्नहरू किनारमा मात्र जुध्छन्। ऐनामा सही प्रमाणपत्रले ऐना ऐना नै हो भनी प्रमाणित गर्छ; ऐनामा नबदलेको प्रकाशक सामग्री छ भनी प्रमाणित गर्दैन। हस्ताक्षर गरिएको प्याकेजले प्रकाशकले हस्ताक्षर गरेको प्रमाणित गर्छ; नेटवर्कले नयाँ संस्करण पुर्याएको वा तपाईंले देखाएको भण्डार तपाईंको संस्थाले स्वीकृत गरेको हो भनी भन्दैन।

मानिसहरूले जाँच बन्द गरेर बनाउने असफलता अवस्था दोस्रो ग्यारेन्टीको स्थायी हानि हो, एउटा सफल डाउनलोडको बदलामा। त्यो साटासाट त्यो महत्त्वपूर्ण हुने दिनसम्म अदृश्य रहन्छ।

apt ले वास्तवमा के प्रमाणित गर्छ

APT को मोडेल प्रमाणित अभिलेख-शृंखला हो। हस्ताक्षर गरिएको रिलिज मेटाडाटा चेकसममार्फत प्याकेज अनुक्रमणिकासम्म पुर्याउँछ, र ती अनुक्रमणिका चेकसममार्फत अलग-अलग प्याकेज फाइलसम्म पुर्याउँछन्। शृंखलाको प्रमाणीकरणले नै ऐनालाई अविश्वसनीय तर प्रयोगयोग्य बनाउँछ: ऐनाले चाहेको जे पनि दिन सक्छ, र मेटाडाटाको हस्ताक्षरले APT ले त्यो स्वीकार्छ कि भन्ने निर्णय गर्छ।

यो जानाजान प्रत्येक स्थापित प्याकेजमा मर्मतकर्ताको हस्ताक्षर जाँच्नुसँग एउटै होइन, र यही भिन्नताले बग रिपोर्टमा «प्याकेज हस्ताक्षरित छ» र «अभिलेख प्रमाणित छ» परस्पर बदलामा प्रयोग हुनुको कारण बताउँछ, जबकि तिनले फरक अर्थ दिन्छन्।

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

अपडेटको आउटपुट पढ्नुहोस्, केवल एक्जिट कोड होइन। APT ले मेटाडाटा असफल भएको भण्डारको नाम भन्छ, र त्यही नाम जाँच्नुपर्ने सीमा हो। हस्ताक्षर प्रमाणीकरणबिना विश्वसनीय भनी चिन्ह लगाइएको भण्डार, वा असुरक्षित भण्डारका लागि ओभरराइड, कसैले गरेको कन्फिगरेसन निर्णय हो र उसले त्यो व्याख्या गर्न सक्नुपर्छ।

ताजगी फेरि अर्को छुट्टै गुण हो। वैध रूपमा हस्ताक्षर गरिएको मेटाडाटा फाइल गत हप्ता देखेको भन्दा पुरानो हुन सक्छ, त्यसैले रिलिज मेटाडाटासँग म्याद हुन्छ र त्यसैले क्लाइन्टमा घडीको समस्याले कुञ्जीको समस्या जस्तो देखिने जाँच त्रुटि उत्पन्न गर्न सक्छ।

dnf5 ले अलग के जाँच्छ

RPM पक्षले दुई फरक स्विच दिन्छ, र तिनलाई मिसाउँदा विपरीत दिशामा त्यही किसिमको गल्ती हुन्छ। एउटाले प्याकेज फाइलमा वैध हस्ताक्षर हुनुपर्छ कि भन्ने नियन्त्रण गर्छ; अर्कोले भण्डार मेटाडाटा हस्ताक्षरित हुनुपर्छ कि भन्ने नियन्त्रण गर्छ। तिनलाई स्वतन्त्र रूपमा सेट गर्न सकिन्छ, र कुनै प्रणाली एउटामा कडा र अर्कोमा नरम हुन सक्छ।

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

प्याकेज प्रश्नले स्थापित प्रतिको हस्ताक्षर मेटाडाटा कस्तो देखिन्छ देखाउँछ, जो कडाइको दाबी गर्ने कन्फिगरेसन फाइलविरुद्ध उपयोगी वास्तविकता-जाँच हो। यसले नभन्ने कुरा वितरणको समर्थित नीति हो, र फोरमको सामान्य «GPG सक्षम गर्नुहोस्» निर्देशनको सट्टा त्यही पालना गर्नुपर्छ।

दुई व्यवस्थापक फरक हुने ठाउँमा भिन्नता स्थापत्यको हो, एउटा कमजोर छ भन्ने संकेत होइन। दुवैले प्रकाशक सामग्री प्रमाणित गर्छन्; तिनले हस्ताक्षरलाई शृंखलाको फरक बिन्दुमा राख्छन्।

सुरुङले के थप्छ र के थप्दैन

VPN ले आवश्यक मार्ग दिन सक्छ, अपडेट ट्राफिक अविश्वसनीय पहुँच नेटवर्कबाहिर राख्न सक्छ र स्थानीय पर्यवेक्षकले देख्ने कुरा घटाउन सक्छ। यी वास्तविक सञ्चालन लाभ हुन्, र तीमध्ये कुनै पनि प्रकाशक प्रमाणीकरण होइन।

HTTPS ले आफ्नै ग्यारेन्टी थप्छ, र त्यो देखिने भन्दा साँघुरो छ। यसले तपाईंले जोडिएको TLS छेउ प्रमाणित गर्छ। त्यो छेउ ऐना भएमा तपाईंले ऐना प्रमाणित गर्नुभयो, त्यसले दिने अभिलेख सामग्री होइन। हस्ताक्षरित मेटाडाटा शृंखला ठ्याक्कै यही अवस्थाका लागि छ।

दुवैमध्ये कुनै नियन्त्रणले उपलब्धताको वाचा गर्दैन। नेटवर्कले डेलिभरी अस्वीकार गर्न सक्छ, र प्रमाणित वस्तु स्वतः नयाँ हुँदैन। ताल्चाको प्रतिमा देखेर अनुमान गर्नुको सट्टा प्याकेज व्यवस्थापकको आफ्नै ताजगी नीति प्रयोग गर्नुहोस्।

असफल भएको सीमाको निदान गर्नुहोस्

केही बदल्नुअघि चरणको नाम भन्नुहोस्: DNS समाधान, प्रोक्सी वा मार्ग, TLS छेउको पहिचान, अभिलेख प्रमाणीकरण, प्याकेज हस्ताक्षर जाँच, वा स्थापना। प्रत्येकको फरक त्रुटि-आकार र फरक मालिक हुन्छ।

नेटवर्क मार्गको मर्मतमा कहिल्यै अज्ञात हस्ताक्षर कुञ्जीलाई विश्वसनीय घोषणा गर्नु, प्रमाणपत्र बेवास्ता गर्नु, वा तपाईंले नमागेको भण्डार कन्फिगरेसन स्वीकार गर्नु पर्नुहुँदैन। कुञ्जी साँच्चै फेरिएको भए, वितरण वा भण्डारको मालिकले नयाँ कुञ्जी तपाईंले प्रमाणित गर्न सक्ने माध्यमबाट प्रकाशित गर्छ, र त्यही लागू गर्नुपर्ने सुधार हो।

कुन सीमा असफल भयो र त्यसको मालिक को हो लेख्नुहोस्। अर्को अपडेट असफलता अर्को सीमामा हुनेछ, र सूची हुँदा सुरुङले अपडेट सुरक्षित बनाउँछ कि भन्ने अर्को बहसको सट्टा पाँच मिनेटको निदान बन्छ।