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 टोकाची ओळख, संग्रह प्रमाणीकरण, पॅकेज स्वाक्षरी तपासण्या, किंवा स्थापना। प्रत्येकाचा वेगळा त्रुटी-आकार आणि वेगळा मालक आहे।

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

कोणती सीमा अयशस्वी झाली आणि तिचा मालक कोण आहे ते लिहा। पुढील अपडेट अयशस्वीता दुसऱ्या सीमेवर असेल, आणि यादी असल्याने बोगदा अपडेट सुरक्षित करतो का या आणखी एका वादाऐवजी पाच मिनिटांचे निदान होते।