संक्षेप में जवाब
GitHub की 30 सितंबर की सूचना के अनुसार डेटा रेज़िडेंसी क्लाउड में केवल X25519 देने वाले TLS क्लाइंट 7 अक्टूबर से नहीं जुड़ पाएँगे। समीक्षा खास तौर पर जानबूझकर सीमित की गई सेटिंग की है।
सीमा स्पष्ट है, लेकिन पृष्ठ का पता भ्रमित कर सकता है
GitHub की 30 सितंबर 2026 की सूचना के अनुसार 7 अक्टूबर से डेटा रेज़िडेंसी वाले GitHub Enterprise Cloud पर केवल X25519 समूह पेश करने वाले TLS क्लाइंट स्वीकार नहीं होंगे। GHE.com TLS समयसीमा किसी निश्चित सेवा और क्लाइंट कॉन्फ़िगरेशन के लिए है। घोषणा के पते में 15 सितंबर लिखा रह गया है, जबकि दिखाई देने वाला शीर्षक और मुख्य पाठ दोनों 7 अक्टूबर कहते हैं। यहाँ तारीख का आधार वही पाठ है।
रखरखाव की टिकट में लिंक भेजने वाले प्रशासक के लिए यह अंतर महत्वपूर्ण है। पते से उठाई तारीख अनावश्यक भ्रम पैदा कर सकती है। अंतिम दिन के साथ प्रभावित सेवा और सूचना की तारीख लिखना उपयोगी है। इससे अगले सहयोगी को समझ आता है कि संगतता समीक्षा क्यों हो रही है और उसके दायरे में वास्तव में कौन से सिस्टम आने चाहिए।
दोनों पक्षों को साझा कुंजी समझौता समूह चाहिए
HTTPS कनेक्शन में TLS शुरुआत में संगत क्रिप्टोग्राफ़िक मापदंड तय करता है। IETF का 2018 में प्रकाशित TLS 1.3 मानक secp256r1 और X25519 जैसे नाम वाले समूह बताता है। मानक के अनुरूप TLS 1.3 ऐप को secp256r1, जिसे सामान्यतः P-256 कहते हैं, समर्थन करना भी आवश्यक है। यह दस्तावेज़ तकनीकी संदर्भ देता है; GitHub की नई समय सीमा उससे नहीं आती है।
उपयोगी अंतर X25519 उपलब्ध होने और केवल उसी तक सीमित होने में है। स्वीकार्य विकल्प देने वाला क्लाइंट संगत कनेक्शन बना सकता है। कोई विकल्प न देने वाला क्लाइंट तब नहीं जुड़ सकेगा जब सर्वर उसके एकमात्र चुनाव को अस्वीकार कर दे। इसलिए वास्तव में पेश किए जा रहे समूहों की सूची अधिक प्रासंगिक है, केवल यह कहना नहीं कि उत्पाद एन्क्रिप्शन इस्तेमाल करता है।
क्लाइंट कोई मध्यस्थ उपकरण भी हो सकता है
GitHub के अनुसार प्रभावित एंडपॉइंट P-256 और P-384 को समर्थन देते रहेंगे और अधिकतर वर्तमान क्लाइंट P-256 पहले से जानते हैं। जोखिम उन ऐप, प्रॉक्सी, सुरक्षा उपकरणों और लाइब्रेरी में है जिन्हें स्पष्ट रूप से केवल X25519 देने के लिए सेट किया गया है। किसी डेवलपर के लैपटॉप में आधुनिक ब्राउज़र होना पूरे संगठन के हर स्वचालित कनेक्शन का प्रमाण नहीं है।
एक उदाहरण में बिल्ड जॉब का बाहरी कनेक्शन प्रॉक्सी से होकर जा सकता है। संबंधित सेटिंग मध्यस्थ पर या जॉब के रनटाइम में हो सकती है। अलग लैपटॉप की जाँच अलग रास्ता अपनाएगी। हमारा आकलन है कि सुधार तय करने से पहले वास्तविक कनेक्शन बनाने वाले घटक, उसके मार्ग और जिम्मेदार व्यक्ति को पहचानना चाहिए। सामने दिखने वाली ऐप हमेशा सीधे अंतिम सर्वर से बातचीत नहीं करती।
लक्षित समीक्षा सूचना के आकार के अनुरूप है
कंपनी समर्थित ऑपरेटिंग सिस्टम, रनटाइम, CLI, प्रॉक्सी और TLS लाइब्रेरी इस्तेमाल करने, केवल X25519 वाली सीमा हटाने और P-256 चालू करने को कहती है। P-384 भी उपलब्ध विकल्प है। GitHub स्पष्ट कहता है कि अधिकतर ग्राहकों को कार्रवाई की ज़रूरत नहीं। इसलिए सूचना खास कॉन्फ़िगरेशन जाँच का आधार है, हर उद्यम सिस्टम दोबारा बनाने का सामान्य आदेश नहीं।
आंतरिक रिकॉर्ड में घटक, उसके पेश किए गए समूह, संपर्क का एंडपॉइंट और बदलाव के जिम्मेदार व्यक्ति का नाम रखा जा सकता है। सत्यापन वास्तविक रनटाइम और नेटवर्क रास्ते से होना चाहिए। तालिका इन्हीं दायरे संबंधी निर्णयों को स्पष्ट करती है। कोई एक सार्वभौमिक कमांड नहीं दिया गया, क्योंकि अलग लाइब्रेरी और उपकरण अपनी सेटिंग अलग तरीके से दिखाते हैं और गलत मार्ग की जाँच भ्रामक भरोसा दे सकती है।
| कनेक्शन या सेटिंग | सूचना में स्थिति | व्यावहारिक अर्थ |
|---|---|---|
| GHE.com HTTPS, केवल X25519 | 7 अक्टूबर से प्रभावित | पहले समर्थित विकल्प चालू करें |
| P-256 वाला GHE.com HTTPS | समूह समर्थित रहेगा | वास्तविक सेटिंग और रास्ता जाँचें |
| P-384 | यह भी समर्थित रहेगा | अतिरिक्त संगत विकल्प |
| SSH कनेक्टिविटी | स्पष्ट रूप से अप्रभावित | इस सूचना के कारण SSH कुंजी बदलना आवश्यक नहीं |
SSH बाहर है, पर एक प्रक्रिया में कई प्रोटोकॉल हो सकते हैं
GitHub कहता है कि SSH कनेक्टिविटी प्रभावित नहीं है। HTTPS के TLS समूह को उपयोगकर्ता की SSH कुंजी या Git रिमोट की पहचान विधि के साथ मिलाना गलत होगा। सूचना SSH कुंजियाँ बदलने को नहीं कहती। यह अंतर स्पष्ट रखने से केवल संगतता की जाँच के नाम पर असंबंधित प्रणालियों में क्रेडेंशियल बदलने का अनावश्यक काम नहीं बनता।
फिर भी एक वर्कफ़्लो अलग नेटवर्क ऑपरेशन कर सकता है। उदाहरण के लिए रिपॉज़िटरी SSH से ली जाए और बाद के चरण में कोई सेवा HTTPS से बुलाई जाए। यह सामान्य आर्किटेक्चर का उदाहरण है, किसी खास GitHub वर्कफ़्लो के असफल होने का दावा नहीं। हर संबंधित कनेक्शन देखना पूरे पाइपलाइन को SSH पाइपलाइन कहकर समीक्षा समाप्त करने से अधिक जानकारी देता है।
जानबूझकर लगाई सीमाओं का जिम्मेदार होना चाहिए
सितंबर की सूचना सेवा की नीति और भविष्य में अस्वीकार किए जाने की शर्त बताती है। वह X25519 में नई खोजी गई कमजोरी सिद्ध नहीं करती, पोस्ट-क्वांटम बदलाव की घोषणा नहीं करती और प्रदर्शन की तुलना भी नहीं देती। मानक कनेक्शन की बातचीत समझाता है, लेकिन उसके आधार पर ऐसा व्यापक सुरक्षा कारण नहीं जोड़ना चाहिए जो GitHub ने इस घोषणा में बताया ही नहीं।
व्यावहारिक सीख है कि किसी जानबूझकर लगाए प्रतिबंध का मालिक और पुनरावलोकन की तारीख होनी चाहिए। पहले किसी कारण से चुनी गई सेटिंग बाहरी सेवा बदलने पर संगतता बाधा बन सकती है। यहाँ काम ठोस है: प्रभावित केवल-X25519 कॉन्फ़िगरेशन पहचानना और 7 अक्टूबर से पहले स्वीकार्य विकल्प सत्यापित करना, साथ में यह स्पष्ट रखना कि सूचना किन सिस्टम पर लागू है।
सवाल और जवाब
क्या हर GitHub ग्राहक प्रभावित होगा?
नहीं। सूचना केवल डेटा रेज़िडेंसी वाले GitHub Enterprise Cloud के लिए है। GitHub कहता है कि अधिकतर ग्राहकों को कुछ करने की ज़रूरत नहीं, क्योंकि आधुनिक ब्राउज़र, सिस्टम, CLI और सामान्य TLS लाइब्रेरी P-256 पहले ही समर्थन करते हैं।
सही तारीख 15 सितंबर है या 7 अक्टूबर?
30 सितंबर की सूचना के URL में 15 सितंबर बचा हुआ है, लेकिन उसके वर्तमान शीर्षक और मुख्य पाठ में 7 अक्टूबर 2026 साफ़ लिखा है। इस लेख में जाँचे गए पाठ की तारीख इस्तेमाल हुई है।
क्या SSH कुंजियाँ बदलनी पड़ेंगी?
नहीं। GitHub ने SSH कनेक्टिविटी को स्पष्ट रूप से इस बदलाव से बाहर रखा है। विषय HTTPS के लिए TLS कुंजी समझौते के समूह हैं। फिर भी कोई वर्कफ़्लो SSH से रिपॉज़िटरी लेने के बाद दूसरे चरण में HTTPS इस्तेमाल कर सकता है।