Git 2.56 — और 3.0 — की प्रतीक्षा

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

Git 2.56 और एक संभावित 3.0 को लेकर बहस इस बात पर केंद्रित है कि SHA‑1 से SHA‑256 पर बिना history, tooling, या signatures तोड़े कैसे जाया जाए, और उस संक्रमण के दौरान integrity कैसे सत्यापित की जाए। टिप्पणीकार Rust को सुरक्षित internals के लिए अपनाने, reftable और pluggable backends जैसे नए storage mechanisms को filesystem-based refs के बदले लाने, और conflict styles, defaults, तथा change IDs के समर्थन जैसी लंबे समय से चली आ रही usability समस्याओं को सुधारने के लाभ और trade-offs पर भी विचार करते हैं। व्यापक security प्रश्न भी सामने आते हैं, जिनमें hash choices और quantum threats का संबंध तथा यह कि क्या incremental changes बड़े C codebase में सुरक्षा को वास्तव में बेहतर बनाते हैं।

SHA-256 माइग्रेशन और इतिहास का पुनर्लेखन

  • कई टिप्पणियों में बहस होती है कि SHA-1 से SHA-256 पर जाना क्या force-pushes और history rewrites की मांग करता है।
  • चिंताएँ: forced pushes के दौरान history tampering का जोखिम; issues, comments और code में SHA-आधारित references का अमान्य होना; shallow clones का टूटना; मौजूदा commit signatures का अमान्य हो जाना।
  • कुछ लोग नोट करते हैं कि content blobs नहीं बदलते, इसलिए SHA-1 और SHA-256 histories को rehash करके तुलना की जा सकती है, लेकिन इससे history corruption नहीं रुकती।
  • अन्य लोग यह उजागर करते हैं कि Git SHA-1 और SHA-256 repos को freely mix नहीं करेगा (जैसे, submodules), जिससे लंबे समय तक चलने वाले dual-repo setups और mapping tables का संकेत मिलता है।
  • दस्तावेज़ीकरण से लगता है कि यह बदलाव केवल एक hard cut-over नहीं, बल्कि compatibility layers और lookup tables के साथ एक repack जैसा है।

Git में Rust अपनाना

  • एक पक्ष का तर्क है कि Rust को अनावश्यक रूप से “थोपा” जा रहा है और Rust का एक छोटा हिस्सा सुरक्षा में कोई खास सुधार नहीं लाता।
  • अन्य लोग जवाब देते हैं कि:
    • क्रमिक सुधार महत्वपूर्ण हैं, खासकर नए code और parsers के लिए, जहाँ C में memory-safety CVEs का लंबा इतिहास है।
    • नए components के लिए safer languages का उपयोग तर्कसंगत है, भले ही legacy C बना रहे।
  • वैकल्पिक “safe C” approaches (जैसे, Fil-C) पर भी चर्चा है, जिसमें performance और memory के trade-offs बताए गए हैं।

Storage backends, refs, और reftable

  • कुछ लोग Git को “slow files” छोड़कर “proper database” अपनाते देखना चाहते हैं।
  • प्रतिवाद: filesystem पहले से ही एक non-relational database है; performance समस्याएँ नए use cases (बहुत सारे refs, hub-style workflows) से आती हैं।
  • pluggable backends पर काम चल रहा है (refs के लिए reftable; object stores के वैकल्पिक रूप जैसे SQLite, S3, आदि)।
  • reftable की प्रशंसा इसलिए की जाती है कि यह ref-name/path issues और case-sensitivity समस्याओं को हल करता है, लेकिन tooling (जैसे libgit2, shell integrations) के साथ compatibility एक चिंता है।

Defaults, UX, और workflow features

  • Git 3.0 से “bad defaults” ठीक करने के अनुरोध, जिनमें शामिल हैं:
    • अधिक सुरक्षित push defaults (--force-with-lease, auto remote setup)।
    • बेहतर conflict style (zdiff3), improved submodule diffs और recursion, और rerere को सक्षम करना।
  • कुछ लोग commits के लिए standardized “change IDs” का समर्थन करते हैं (जैसे Gerrit, jj, GitButler में), ताकि per-commit review, stacked changes, और rebases के दौरान stable IDs मिल सकें; मौजूदा Git commands अक्सर ऐसे headers हटा देते हैं।
  • “simple snapshotting” पर विभिन्न विचार हैं: git stash का उपयोग, dedicated WIP branches/tags, या बाहरी snapshotting tools।

Security और quantum चिंताएँ

  • चर्चा स्पष्ट करती है कि:
    • Length-extension attacks Git के hashes के उपयोग के लिए प्रासंगिक नहीं हैं।
    • Quantum threats मुख्यतः asymmetric crypto को प्रभावित करते हैं; symmetric ciphers और hashes में अधिकतम square-root security reduction होता है।
  • SHA-256 को पर्याप्त माना जाता है; SHA-3 पर अभी स्विच करना अव्यावहारिक समझा जाता है, क्योंकि लंबी transition work पहले से ही की जा चुकी है।

Miscellaneous

  • GitHub और Bitbucket के SHA-256 support में पीछे रहने पर टिप्पणियाँ, हालांकि बताया गया है कि GitHub के private previews मौजूद हैं।
  • reftable के default बनने में रुचि, साथ ही integer commit IDs (जैसे Mercurial में) और refs को प्रभावित करने वाले filesystem crash behaviors पर side debates।