Git'in önerdiği SHA-256 varsayılanı, GitHub'ın kurucu ortaklarından 'maliyetli bir hata' itirazı aldı

Git'in 3.0 sürümüne ilişkin taslak plan, yeni oluşturulan depoların varsayılan nesne formatını SHA-1'den SHA-256'ya çevirmeyi öngörüyor ve platformun kurucularından biri tarafından sert bir kamuoyu itirazıyla karşılandı. 1 Ekim'de Scott Chacon — hem GitHub'ın hem de Git istemcisi GitButler'ın kurucu ortası — bu planı "maliyetli bir hata" olarak nitelendirdi. Teklifin dev.to analizine göre anlaşmazlık aslında daha güçlü hash algoritmalarının istenip istenmediğiyle ilgili değil; geçişin, Git'in mevcut tanımlayıcıları üzerine kurulu her araç ve servise ne kadar göç işi yüklediğiyle ilgili.

Teklifin gerçekte neyi değiştirdiği

Git 3.0 kırıcı değişiklikler belgesi, varsayılanın yalnızca yeni depolar için sha1'den sha256'ya çevrilmesini öneriyor ve bu değişikliği kütüphaneler, uygulamalar ve barındırma servislerindeki hazırlığa bağlıyor. dev.to yazısı, özetlerden çoğu zaman düşürülen iki nüansa dikkat çekiyor: planlanan bir sürüm tarihi yok ve SHA-1'in terk edilmesi planlanmıyor. Mevcut depolar, Git çalıştırılabilir dosyası yükseltildiğinde nesne formatlarını koruyor; yani kimse ilk günden geçmişini yeniden yazmak zorunda kalmıyor.

Değişikliğin alterdiği şey başka bir karardır: varsayılan bir kez değiştiğinde, yepyeni bir proje için nesne formatı seçimi daha sonuç doğuran bir karar haline gelir, çünkü bu seçim artık kurulu tabandan ayrışır.

Yeni bir hash neden tüm geçmişe ulaşır

Git hash'leri süs olarak göstermez; nesnelere onlarla adres verir. Blob'lar dosya içeriklerini tutar, tree'ler diğer nesnelere atıfta bulunur, commit'ler tree'lere ve önceki commit'lere işaret eder — hepsi isimle. Algoritmayı değiştirin ve her nesne ismi değişir; nesneler birbirlerinin isimlerini gömdüğü için değişiklik tüm depo yapısına yayılır. dev.to makalesinin belirttiği gibi, bir web sayfasında gösterilen bir etiketi güncellemek, altta yatan bu referansları çözümsüz bırakır.

Makaledeki aynı içerikli bir gösterim, özdeş içerik için 40 karakterlik bir SHA-1 nesne ismi ve 64 karakterlik bir SHA-256 ismi üretti — ve ikisi de Git'in iç nesne çerçevesini içerdiğinden düz dosya sağlama değeri (checksum) değillerdir. Chacon'un ekosistem acısı öngörüsü tam olarak bu yüzezi hedefliyor: 40 karakterlik tanımlayıcıları sabit kodlamış araçlar, nesne isimlerine sabitlenmiş bağlantılar ve imza yönetimi. Resmî geçiş tasarımı SHA-1 ve SHA-256 isimleri arasında eşlemeler, imza temsilleri ve aşamalı uyumluluk içeriyor; ama bunlar tasarım hedefleri — bir bakımcı, ilgili parçaları anlayan bir uygulamaya hâlâ ihtiyaç duyar ve kullanıcılar fiilen hangi sürümü çalıştırdıklarını bilmek zorundadır.

Güvenlik argümanı ve karşı öneri

Güvenlik gerekçesinin belgelenmiş bir geçmişi var. Git'in kendi arka plan materyali, 2017'deki pratik SHAttered çarpışmasını kaydeder ve Git 2.13.0 sonrası sürümler varsayılan olarak sertleştirilmiş SHA-1 kullanır; bu da o saldırıya karşı korur. 2020'deki SHA-1 is a Shambles araştırması daha da ileri giderek seçilmiş önek (chosen-prefix) çarpışmaları ve bir PGP kimlik taklidi gösterdi — ancak dev.to yazarının işaret ettiği gibi, güncel sertleştirilmiş Git'in kırıldığını göstermedi.

Chacon, ekosistem faturasının çok az ek koruma satın aldığını savunuyor. Nesne adreslemesini, imzalı nesnelere dahil edilebilecek güçlü bir tree içerik hash'inden ayırmayı öneriyor; bir kavram kanıtına ve mevcut git-evtag yaklaşımına işaret ediyor. Ayrıca Linus Torvalds'ın 2005'teki "Gerçek güvenlik dağıtımdadır" sözüne yaslanıyor. dev.to yazarı ölçülü bir tutum takınıyor: Chacon'un uyumluluk endişesi dinlenmeyi hak ederken, hem sertleştirilmiş SHA-1'in zaten sağladığı koruma hem de gelecekteki saldırılara direnç gerekçesi doğru biçimde ifade edilmeyi hak ediyor. Resmî geçiş ile alternatif arasındaki seçimi bağımsız bir performans karşılaştırması netleştirmiyor.

Uyumluluk testleri ne gösterdi

Makaledeki testler endişenin arkasına kanıt koyuyor. Git 2.34.1 kullanılarak SHA-1 bir fikstür deposundan SHA-256 birine yapılan fetch, 128 koduyla ve "fatal: mismatched algorithms: client sha256; server sha1" hatasıyla sonlandı — bu da formatlar arasında şu anda birlikte çalışabilirlik olmadığı yönündeki git-init dokümantasyonu ifadesiyle tutarlı. Test yayımlanmış bir Git sürümünü ölçtü, Git 3'ün nihai davranışını değil.

GitHub daha dar bir olumlu sinyal verdi. Bakımcı Brian Carlson'ın herkese açık konuşma deposuna salt-okunur bir ls-remote, 64 karakterlik bir HEAD döndürdü ve tam o revizyondaki slaytlar SHA-256'nın artık özel önizlemede olduğunu — depo oluşturmanın hâlâ kamuya açık olmadığını belirtiyor. Yazma işlemi, sıradan proje oluşturma veya entegrasyon uyumluluğu test edilmedi; yani sonuç genel kullanılabilirlik hakkında bir şey söylemiyor.

Neden önemli

Bu bir acil durum değil ama Git'i barındıran, saran veya betikleyen herkes için bir planlama sinyali. Git düzeyindeki bir varsayılan değişikliği, üzerindeki her katmanda bir destek sorunu haline gelir: depo barındırıcıları SHA-256 depalarını sunmaya yeni başlıyor, CI entegrasyonları kendi Git kütüphanelerini gömüyor ve dahili araçlar nesne isimleri hakkında sabit genişlik varsayımları taşıyor olabilir. Daha uzun tanımlayıcıları kabul eden bir betik ile sabit kodlanmış uzunluğa sahip bir parser çok farklı işlerle karşı karşıyadır.

dev.to yazısından pratik tavsiye, şimdi tek kullanımlık projelerle test etmek: bir commit'in kurumunuz içinde izlediği gerçek yolu seçin, her aşamanın hangi Git uygulamasını kullandığını kontrol edin ve sabit uzunluklu tanımlayıcı varsayımları ile saklanan ya da bağlantılanmış nesne isimleri için denetim yapın. Tek bir regular expression değiştirmek her uyumluluk sorusunu yanıtlayamaz — ve ekipler maruziyetlerini ne kadar erken haritalandırırsa, hangi tasarım tartışmayı kazanırsa kazansın nihai göç o kadar ucuz olur.