GitHub CLI की आधिकारिक Linux पैकेज रिपॉजिटरी की पुरानी PGP कुंजी 5 सितंबर 2026 को समाप्त हो गई। GitHub की 3 सितंबर की सूचना के अनुसार, 8 अप्रैल 2026 से पहले जोड़े गए और बाद में नहीं सुधारे गए APT या RPM विन्यास में अब स्थापना तथा अपडेट हस्ताक्षर-जांच पर रुक सकते हैं।
सीधा सुधार पुरानी कुंजी पर भरोसा बनाए रखना नहीं, बल्कि GitHub CLI की प्रतिस्थापन कुंजी लेना और यह सुनिश्चित करना है कि पैकेज प्रबंधक उसी का उपयोग कर रहा हो। सितंबर के स्वतंत्र रिलीज अभिलेख में भी दर्ज है कि नई रिपॉजिटरी सामग्री और नए RPM पैकेज प्रतिस्थापन कुंजी से हस्ताक्षरित होंगे; पहले से स्थापित GitHub CLI कार्यक्रम केवल कुंजी समाप्त होने से बंद नहीं होता।
पहले तय करें कि स्थापना प्रभावित है या नहीं
जांच तभी जरूरी है जब मशीन Linux पर चलती हो, GitHub CLI आधिकारिक APT या RPM रिपॉजिटरी से आया हो और उसका भरोसा-विन्यास 8 अप्रैल 2026 से पहले बनाया गया हो। इन तीनों में से कोई शर्त पूरी न होने पर इस कुंजी-परिवर्तन को विफलता का कारण मानना उचित नहीं है।
APT का दायरा मुख्यतः Debian और Ubuntu को समेटता है। RPM वाला दायरा Fedora, RHEL, CentOS, Amazon Linux 2, openSUSE और SUSE पर DNF, Yum या Zypper के माध्यम से जोड़ी गई आधिकारिक रिपॉजिटरी तक जाता है। केवल मशीन पर GitHub CLI मौजूद होना पर्याप्त संकेत नहीं है; असली प्रश्न यह है कि पैकेज किस स्रोत से आया और स्थानीय प्रणाली किस हस्ताक्षर कुंजी पर भरोसा करती है।
Windows और macOS की स्थापनाएं इस बदलाव के दायरे में नहीं हैं। Homebrew, Conda, सामुदायिक पैकेज प्रबंधक, स्रोत कोड से बनाया गया कार्यक्रम, GitHub Releases से सीधे लिया गया पैकेज या अलग संग्रह से निकाली गई निष्पादनयोग्य फाइल भी इस APT/RPM रिपॉजिटरी कुंजी पर निर्भर नहीं होती। इन रास्तों में अपडेट विफल हो तो दूसरी वजह तलाशनी होगी।
त्रुटि संदेश और फिंगरप्रिंट क्या बताते हैं
APT पर प्रभावित मशीन में EXPKEYSIG 23F3D4EA75716059 या NO_PUBKEY 5612B36462313325 दिख सकता है। RPM प्रणालियां हस्ताक्षर सत्यापन विफल होने, GPG जांच असफल होने या अज्ञात कुंजी का संदेश दे सकती हैं। ये GitHub खाते, SSH कुंजी या GitHub CLI प्रमाणीकरण की समस्याएं नहीं हैं।
GitHub CLI की तकनीकी सूचना पुरानी कुंजी का पूरा फिंगरप्रिंट 2C6106201985B60E6C7AC87323F3D4EA75716059 और नई कुंजी का फिंगरप्रिंट 7F38BBB59D064DBCB3D84D725612B36462313325 देती है। उसी पृष्ठ पर APT, DNF, Yum और Zypper के लिए आधिकारिक आदेश तथा अपेक्षित त्रुटियां दी गई हैं।
Debian या Ubuntu पर /etc/apt/sources.list.d/github-cli.list खोलकर देखें कि signed-by किस फाइल की ओर संकेत करता है। फिर GPG से उसी फाइल की कुंजियां दिखाएं। सामान्य नया स्थान /etc/apt/keyrings/githubcli-archive-keyring.gpg है, लेकिन पुराने विन्यास में संदर्भित फाइल /usr/share/keyrings/ के भीतर भी हो सकती है। केवल पुराना फिंगरप्रिंट मिलने पर बदलाव चाहिए; नया फिंगरप्रिंट मौजूद हो तो पहले सामान्य रिपॉजिटरी ताज़ाकरण दोहराना अधिक उचित है।
RPM प्रणाली में स्थापित सार्वजनिक कुंजी प्रविष्टियों का विवरण देखकर पैकेजर का पता [email protected] और पूरा फिंगरप्रिंट मिलाएं। छोटा कुंजी पहचानकर्ता अकेले पर्याप्त नहीं है, क्योंकि गलत प्रविष्टि हटाने से किसी दूसरी रिपॉजिटरी का भरोसा टूट सकता है।
APT में नई कुंजी सुरक्षित ढंग से जोड़ें
APT सुधार में सबसे महत्वपूर्ण बात उस फाइल को बदलना है जिसे रिपॉजिटरी प्रविष्टि वास्तव में पढ़ती है। केवल नई कुंजी को मानक निर्देशिका में रख देने से लाभ नहीं होगा, यदि signed-by अब भी किसी पुराने स्थान की ओर संकेत कर रहा है।
/etc/apt/keyrings निर्देशिका मौजूद न हो तो उसे प्रशासकीय अनुमति से बनाएं।
आधिकारिक पता https://cli.github.com/packages/githubcli-archive-keyring.gpg से कुंजी-फाइल लें और रिपॉजिटरी प्रविष्टि में संदर्भित स्थान पर रखें।
फाइल को APT प्रक्रिया के लिए पठनीय बनाएं और GPG से उसका पूरा फिंगरप्रिंट मिलाएं।
इसके बाद पैकेज सूचियां ताज़ा करें और GitHub CLI की स्थापना या अपडेट फिर चलाएं।
यदि मौजूदा signed-by पथ अलग है, तो या तो उसी संदर्भित फाइल को सुरक्षित रूप से बदलें या रिपॉजिटरी प्रविष्टि को नए पथ के अनुरूप करें। कुंजी मिलने के बाद अपेक्षित फिंगरप्रिंट न दिखे तो स्थापना आगे न बढ़ाएं। हस्ताक्षर-जांच बंद करना या रिपॉजिटरी को बिना सत्यापन भरोसेमंद घोषित करना इस समस्या का सुरक्षित समाधान नहीं है।
कंटेनर और निरंतर एकीकरण निर्माण में पुरानी कुंजी कैश की हुई परत में रह सकती है। ऐसे मामले में कुंजी लेने वाली परत दोबारा बनानी होगी; मेजबान मशीन की फाइल बदलने से कंटेनर का अलग फाइल तंत्र अपने-आप नहीं बदलता।
RPM में रिपॉजिटरी विन्यास दोबारा लें
RPM परिवार में नई कुंजी सामान्यतः रिपॉजिटरी विन्यास फिर से लेने और अगले पैकेज अपडेट के दौरान उसे सत्यापित करने से आती है। Fedora के नए संस्करणों में DNF5, पुराने Fedora तथा RHEL/CentOS में DNF4, Amazon Linux 2 में Yum और SUSE परिवार में Zypper के लिए आदेश अलग हैं; इसलिए दूसरे पैकेज प्रबंधक का आदेश न अपनाएं।
DNF5 में मौजूदा रिपॉजिटरी को आधिकारिक gh-cli.repo फाइल से अधिलेखित करें और फिर GitHub CLI अपडेट चलाएं।
DNF4 और Yum में आधिकारिक रिपॉजिटरी पता दोबारा जोड़ें, फिर पैकेज अपडेट करें।
Zypper में पुरानी gh-cli रिपॉजिटरी प्रविष्टि हटाकर आधिकारिक पता फिर जोड़ें और उसके बाद अपडेट चलाएं।
जब पैकेज प्रबंधक नई कुंजी आयात करने की अनुमति मांगे, तब दिखाए गए पूरे फिंगरप्रिंट को प्रतिस्थापन फिंगरप्रिंट से मिलाना जरूरी है। रिपॉजिटरी दोबारा जोड़ने के बाद भी पुरानी कुंजी वाली त्रुटि आए तो केवल उस RPM सार्वजनिक कुंजी प्रविष्टि को हटाएं जिसका पैकेजर और पूरा फिंगरप्रिंट दोनों GitHub CLI की समाप्त कुंजी से मेल खाते हों।
सुधार सफल होने की पहचान
APT में सफलता का अर्थ है कि संदर्भित कुंजी-फाइल में नया फिंगरप्रिंट दिखे और पैकेज सूची GitHub CLI हस्ताक्षर त्रुटि के बिना ताज़ा हो। RPM में रिपॉजिटरी की सामग्री सत्यापित होनी चाहिए और GitHub CLI पैकेज की जांच नई कुंजी के साथ पूरी होनी चाहिए। सिर्फ फाइल डाउनलोड हो जाना सफलता का प्रमाण नहीं है।
नई कुंजी पहले से मौजूद हो तो उसे अनावश्यक रूप से बदलने की जरूरत नहीं है। मौजूदा स्थिति में असर पुराने, असुधारे आधिकारिक APT/RPM भरोसा-विन्यास तक सीमित है; स्थापित कार्यक्रम, GitHub खाता और दूसरी स्थापना विधियां इस घटना से अपने-आप निष्क्रिय नहीं हुई हैं।
