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 छोर की पहचान, संग्रह प्रमाणीकरण, पैकेज हस्ताक्षर जाँच, या इंस्टॉलेशन। हर एक का अलग त्रुटि-आकार और अलग स्वामी है।

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

लिख लें कि कौन-सी सीमा विफल हुई और उसका स्वामी कौन है। अगली अपडेट विफलता किसी दूसरी सीमा पर होगी, और सूची होने से वह सुरंग अपडेट को सुरक्षित बनाती है या नहीं इस बहस के बजाय पाँच मिनट का निदान बन जाती है।