Git 3.0 का आगामी SHA-256 डिफ़ॉल्ट एक महंगी गलती होगा

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

Git के version 3.0 में SHA‑1 से SHA‑256 को डिफ़ॉल्ट hash format बनाने की योजना को लेकर चिंता है कि यह बदलाव ecosystem को fragment कर देगा और उन दशकों पुराने tooling, references, और workflows को तोड़ देगा जो 40-character commit IDs पर निर्भर हैं। आलोचकों का कहना है कि SHA‑1 की कमजोरियाँ Git के वास्तविक threat model के लिए काफी हद तक सैद्धांतिक हैं, और मजबूत hashes को core ID format को incompatible तरीके से बदलने के बजाय एक अतिरिक्त integrity या signing mechanism के रूप में जोड़ा जाना चाहिए। migration के समर्थकों का तर्क है कि hash security अब regulatory और supply-chain आवश्यकता बन चुकी है, लेकिन व्यापक चिंता यह है कि चुना गया रास्ता Python 2→3 जैसी पिछली दर्दनाक transitions जैसा है, खासकर submodules, CI systems, और लंबे समय से चल रहे corporate repositories के संदर्भ में।

SHA‑1 की असुरक्षा कितनी गंभीर है?

  • कई लोगों का तर्क है कि SHA‑1 पहले ही “टूट” चुका है (chosen-prefix collisions, Shambles, आदि) और अखंडता या signatures के लिए उस पर निर्भर रहना असुरक्षित है।
  • अन्य लोग कहते हैं कि वास्तविक Git repos पर व्यावहारिक हमले अभी भी बेहद कठिन हैं, खासकर Git के object format और sha1dc collision-detection को देखते हुए, और कि अधिक संभावित supply-chain हमले maintainer compromise या infrastructure के जरिए आते हैं, hashes के जरिए नहीं।
  • इस पर मतभेद है कि Git hashes “security” हैं या केवल consistency identifiers; कुछ लोग इंगित करते हैं कि commits पर signatures और hash से pinning, इन्हें परोक्ष रूप से security-critical बना देता है।

SHA-256 को डिफ़ॉल्ट बनाने का प्रभाव

  • समर्थक: अंततः SHA‑1 को retire करना ही होगा; देरी करने से केवल future cut-over और खराब होगा। Defaults बदलने ही होंगे, वरना कोई move नहीं करेगा।
  • आलोचक: default बदलने से दो incompatible repo types बनेंगे, जिससे confusion, 40-char hashes मानने वाले broken tools, और formats न समझने वाले users के लिए hard-to-debug failures होंगे। कई लोग इसे IPv6 या Python 3 migrations से जोड़कर देखते हैं।

Submodules, tooling, और ecosystem compatibility

  • एक बड़ा डर submodule breakage का है: SHA‑1 parents के साथ SHA‑256 submodules (और इसके उलट) को पहले unsupported बताया गया था।
  • एक commenter ने प्रयोगात्मक रूप से दिखाया कि हाल के Git में SHA‑256 repo के भीतर SHA‑1 submodules काम कर रहे हैं, लेकिन long-term guarantees और corner cases अभी भी अस्पष्ट हैं।
  • बड़े ecosystems (Yocto, Nix, CI/CD, language package managers) commit hashes पर निर्भर करते हैं; global history rewrites से configs, docs, issue trackers, आदि में references अमान्य हो जाएंगे।

Forges और UX (GitHub, GitLab, self-hosted)

  • चिंता है कि forges users को ऐसे format choices दिखाएंगे जिन्हें वे समझते नहीं, या पहली push पर auto-detection को गलत संभालेंगे।
  • अन्य लोग जवाब देते हैं कि servers पहली push से format infer कर सकते हैं और Git की documented hash-transition plan में interop के लिए SHA‑1↔SHA‑256 mapping शामिल है।

वैकल्पिक डिज़ाइन और प्रस्ताव

  • लोकप्रिय सुझाव:
    • हर object के लिए दोनों hashes स्टोर करना (या separate “tree trust” hash headers), जबकि addressing के लिए SHA‑1 IDs स्थिर रखना।
    • multihash-style self-describing digests का उपयोग करना या एक repo में कई algorithms की अनुमति देना, जैसे Fossil करता है।
    • SHA‑1 को डिफ़ॉल्ट बनाए रखना; SHA‑256 केवल वहाँ जोड़ना जहाँ security या policy इसकी मांग करे।
  • विरोधियों का कहना है कि अलग-अलग hash strengths को मिलाने से कुल सुरक्षा घट सकती है और implementation जटिल हो सकती है।

Security models और खुले प्रश्न

  • realistic attack paths पर बहस: collision-based code smuggling बनाम सरल social या infra attacks।
  • कुछ लोग इस migration को आवश्यक hygiene और future-proofing मानते हैं; अन्य इसे महँगा “security theater” मानते हैं।
  • कई लोगों के लिए यह अभी भी अस्पष्ट है कि Git 3.0 SHA‑1 lookups, submodule interop, और मौजूदा external references को बनाए रखने के लिए कौन-सी exact guarantees देगा।