Apple का git अभी भी समझौता किए गए eMudhra प्रमाणपत्रों पर भरोसा करता है

मूल लेख ↗ Hacker News चर्चा ↗

समझौता किए गए eMudhra TLS certificates को लेकर Apple की हैंडलिंग पर आलोचना हो रही है, क्योंकि macOS अभी भी `/etc/ssl/cert.pem` में एक CA bundle ship करता है जो उन पर भरोसा करता है, जिससे git, curl, Python, और OpenSSL जैसे command-line tools कमजोर बने रहते हैं, जबकि Safari और अन्य GUI apps को Apple के अपने trust framework के जरिए जल्दी सुरक्षित कर दिया गया था। Commenters macOS पर दो अलग-अलग system trust stores के अस्तित्व, Apple की धीमी और manual remediation guidance, और इस बात की आलोचना करते हैं कि OS updates user-applied fixes को चुपचाप उलट सकते हैं। यह घटना operating systems, containers, और languages में fragmented certificate management की गहरी समस्याओं को भी उजागर करती है, और बेहतर centralized revocation तथा trust-store design की मांग को फिर से बल देती है।

असल में क्या टूटा हुआ है

  • समस्या Git से भी बड़ी है: macOS के कई कमांड-लाइन टूल (git, curl, python3, ruby, perl, openssl, आदि) /etc/ssl/cert.pem का उपयोग करते हैं, जिसमें अभी भी ऐसे roots शामिल हैं जो compromised eMudhra intermediates के माध्यम से chains को अनुमति देते हैं।
  • Apple के Security/Keychain stack (Safari, सामान्य Mac apps) का उपयोग करने वाले GUI apps को जल्दी अपडेट कर दिया गया था और वे खराब chain पर भरोसा नहीं करते।
  • macOS में प्रभावी रूप से दो स्वतंत्र trust stores हैं: Apple APIs के लिए Keychain और Unix-style tools के लिए /etc/ssl/cert.pem, जिससे divergence और भ्रम पैदा होता है।

Apple की प्रतिक्रिया और कमियाँ

  • Apple ने एक आधिकारिक support article प्रकाशित किया जिसमें बताया गया है कि उपयोगकर्ता /etc/ssl/cert.pem को manually edit करके कुछ roots (और optionally संबंधित Sectigo roots) हटाएँ।
  • कई commenters इसे अस्वीकार्य मानते हैं: users को sudo shell commands चलाने पड़ते हैं, OS updates से ये बदलाव वापस हो जाते हैं (जैसे macOS 27.2 ने bad certs को restore कर दिया), और कोई तेज़ automated fix जारी नहीं किया गया।
  • कुछ लोग अनुमान लगाते हैं कि Apple CLI tools को second-class मानता है और Unix components के लिए अपने “background/rapid” security update channels का उपयोग करने में धीमा या अनिच्छुक है।

Workarounds और ecosystem की प्रतिक्रियाएँ

  • सुझाए गए mitigations:
    • Apple के निर्देशों का पालन करके /etc/ssl/cert.pem को manually edit करें।
    • Homebrew या MacPorts के curl और OpenSSL versions का उपयोग करें, जो अपने CA bundles ship करते हैं; Homebrew git को system bundle का उपयोग बंद करने के लिए अपडेट कर रहा है।
    • HTTPS के बजाय Git remotes के लिए SSH को प्राथमिकता दें (हालाँकि SSH के अपने trust issues हैं)।
  • Apple के निर्देशों को automate करने के लिए scripts और one-liners साझा किए गए हैं; कुछ लोग random sudo commands को copy-paste करने को सामान्य बनाने के विरुद्ध चेतावनी देते हैं।

Security impact और severity पर बहस

  • कई लोग तर्क देते हैं कि यह एक गंभीर MITM risk है, खासकर public Wi‑Fi या compromised routers पर; mitmproxy जैसे tools पहले से ही खराब chain का दुरुपयोग करने का समर्थन करते हैं।
  • अन्य लोग इसे कम आँकते हैं, कहते हैं कि attackers को local networks पर नियंत्रण चाहिए और अब जब कई devices patched हो चुके हैं तो व्यापक exploitation detectable होगी।
  • कई comments व्यापक PKI समस्याएँ नोट करते हैं: fragmented CA stores (प्रति app, प्रति container, प्रति language), कमजोर या अप्रयुक्त revocation mechanisms, और जब केवल roots packaged हों तो intermediates को साफ़-सुथरे तरीके से distrust करने की कठिनाई।

Meta: Apple, Linux, और trust models

  • कुछ लोग इसे Linux को प्राथमिकता देने का कारण मानते हैं; अन्य लोग counter करते हैं कि सभी platforms पर गंभीर security failures हुए हैं।
  • आलोचना यह भी है कि Apple खुद को security-first के रूप में विपणन करता है, फिर भी अपने Unix tools के लिए prompt, centralized fix जारी करने में विफल रहा।