Git 3.0: SHA-256'ya geçiş ve zorunlu Rust, neden bu kadar tartışılıyor?

Commit kimliği nereden geliyor?

Git’te her commit, dosya ve klasör bir hash ile tanınır. Hash, içeriği alıp ondan sabit uzunlukta bir parmak izi çıkaran bir fonksiyon. Git 2005’ten beri bunun için SHA-1 kullanıyor. git log’da gördüğün 40 karakterlik kimlikler bu yüzden 40 karakter.

Bu parmak izinin işe yaraması için bir kural şart: İki farklı içerik aynı hash’i üretmemeli. Buna çakışma (collision) denir.

SHA-1 neden emekliye ayrılıyor?

SHA-1’in bu kuralı artık tam koruyamadığı biliniyor. ABD standart kurumu NIST onu 2011’de kullanımdan kaldırdı. 2017’de SHAttered saldırısında araştırmacılar, aynı SHA-1 hash’ine sahip iki farklı PDF dosyası üretti. 2020’deki Shambles saldırısı işi daha da ucuzlattı.

Git bu saldırılara karşı boş durmadı. 2.13 sürümünden beri bilinen çakışma denemelerini tespit eden “sertleştirilmiş” bir SHA-1 kullanıyor. Ama Git’in kendi belgesi açık: Donanım güçlendikçe ve yeni saldırılar bulundukça SHA-1’in tamamen kırılması an meselesi. Ekip buna hazırlıklı olmak istiyor.

Git 3.0’da ne değişecek?

Git’in resmî “yaklaşan kırıcı değişiklikler” belgesi şunları sıralıyor. Belge, 3.0 için henüz planlanmış bir tarih olmadığını da söylüyor.

• Yeni depolar SHA-256 ile açılacak. Commit kimlikleri 64 karakter olacak. Mevcut depolara dokunulmuyor ve SHA-1 formatını kaldırma planı yok. Değişikliğin şartı, kütüphanelerin, uygulamaların ve GitHub gibi platformların hazır olması.
• Rust zorunlu olacak. Git, 2.49’dan beri bazı parçaları Rust ile yazıyor. Haziran 2026’da çıkan 2.55 ile Rust desteği varsayılan olarak açıldı, ama hâlâ kapatılabiliyor. 3.0’da bu seçenek kalkacak. Rust’a hemen geçemeyenler için 3.0’dan önceki son sürüm uzun süreli destek alacak: en az dört sürüm boyunca hata, altı sürüm boyunca güvenlik düzeltmesi. Ekip, Linux dağıtımlarına etkisi çok ağır olursa bu adımı erteleyebileceğini de yazıyor.
• Diğer varsayılanlar: Yeni depolarda ana dal main olacak ve referanslar için daha hızlı “reftable” formatı kullanılacak.

Neden bu kadar tartışılıyor?

GitHub’ın kurucularından ve Pro Git kitabının yazarı Scott Chacon, 30 Eylül’de yazdığı yazıda SHA-256 geçişini pahalı ve gereksiz bir “küresel kâbus” olarak nitelendirdi. Argümanları kabaca şöyle:

• 40 karakter bekleyen betikler, CI sistemleri ve araçlar kırılacak. Bir depo SHA-256’ya dönüştürülürse ona verilmiş bütün eski commit bağlantıları geçersiz kalacak.
• SHA-1 ve SHA-256 depoları birbirine push edemiyor. Alt modüller (submodule) de sadece aynı hash türündeki projelerde çalışıyor.
• Gerçek saldırılar hash çakışmasıyla değil, çalınan şifrelerle ve kandırılan bakımcılarla yapılıyor. Linus Torvalds da 2005’te asıl güvenliğin kodun nereden çekildiğinde olduğunu söylemişti.
• Chacon’a göre Google bile yeni projelerde varsayılanı SHA-1’e geri çekmeyi düşünüyor.

Chacon bunun yerine SHA-1’i bırakmadan, commit’lere imzalı ek bir SHA-256 parmak izi eklemeyi öneriyor. Git ekibinin bu öneriye nasıl yaklaşacağı henüz belli değil.

Senin için ne anlama geliyor?

Bugün hiçbir şey değişmiyor. Merak ediyorsan SHA-256’yı şimdiden deneyebilirsin:

git init --object-format=sha256 deneme

Asıl iş, kendi kodunda “hash 40 karakterdir” diye varsayan yerleri bulmak. Kimlik doğrulayan bir düzenli ifade, sabit uzunlukta bir veritabanı sütunu ya da kısaltılmış hash’leri işleyen bir betik, ilk kırılacak yerler.

Düşün

• Kullandığın araçlardan hangisi commit kimliğini bir yerde saklıyor ya da kontrol ediyor?
• Teorik bir güvenlik riski için tüm ekosistemi değiştirmek mi, yoksa sorun gerçekten çıkınca harekete geçmek mi daha doğru?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.