Git 3.0'ın varsayılan SHA-256'ya geçişi, 40 karakterli hash'lere dayalı CI betiklerini tehdit ediyor

Git 3.0 yeni depolarda varsayılan olarak SHA-256 kullanacak

Git'in bir sonraki büyük sürümü, yeni oluşturulan depolar için varsayılan hash algoritmasını SHA-1'den SHA-256'ya çevirecek ve alışılmış 40 karakterlik commit tanımlayıcısını 64 karakterli bir tanımlayıcıya dönüştürecek. dev.to'daki bir analizde belirtildiğine göre, bozulmaların çoğu tam da bu mekanik ayrıntıda ortaya çıkacak: bir hash'in uzunluğunu sessizce varsayan build pipeline'ları, issue takipçileri ve dağıtım betikleri.

Bu değişiklik henüz yürürlükte değil. dev.to yazısının yayınlandığı dönemde güncel olan Git 2.55 itibarıyla SHA-1 hâlâ varsayılan ve yeni davranış yalnızca Git, 3.0 sürümünü tanımlayacak breaking-changes modunda derlendiğinde geçerli; bu sürümün ise bir çıkış tarihi yok. Herkes, bir derlemenin ne kullandığını git init ve ardından git rev-parse --show-object-format komutlarını çalıştırarak kontrol edebilir.

Resmi BreakingChanges dokümantasyonu değişikliğin kapsamını dar tutuyor: yalnızca yeni başlatılan depolar için geçerli, mevcut SHA-1 depoları dönüştürülmeyecek ve SHA-1 nesne formatını emekliye ayırmaya yönelik şu an bir plan yok. Hash-function-transition tasarım dokümanı ise bir deponun tamamen tek formatta olması gerektiğini ve submodule'lerin üst depolarının formatıyla eşleşmek zorunda olduğunu ekliyor.

Kurucu ortağın itirazı

Pro Git kitabının yazarlarından ve hem GitHub'ın hem GitButler'ın kurucusu olan Scott Chacon, bu hafta geçişin pahalı bir hata olacağını savunan bir yazı yayınladı. dev.to yazısına göre yazı, bir günden kısa sürede 549 puanla Hacker News'te üçüncü sıraya yükseldi.

Chacon, SHA-1'in sorunsuz olduğunu iddia etmiyor. 2017'deki SHAttered saldırısı bir çarpışma göstermişti ve 2020'deki SHA-1 is a Shambles araştırması, seçilen-önekli çarpışmaları yaklaşık 2^63 işleme indirdi. Onun argümanı, bu zayıflığın Git'e karşı sömürülmesinin pratik olmadığı: bir saldırganın aynı hash'e sahip iki özdeş dosya varyantı üretmesi ve kurbanların geçmişleri olmadan kötü niyetli olanı fetch etmesini sağlaması gerekiyor. Onun hesabına göre, anlamlı bir çarpışmayı brute-force ile bulmak milyarlarca yıllık GPU zamanı alır, yapay içerik üzerindeki seçilen-önekli saldırılar on binlerce dolara mal olur ve bitkin bir maintainer'a 40.000 dolar vermek çok daha ucuz ve başarıya ulaşma olasılığı daha yüksek.

Onun görüşüne göre göç maliyeti bunun yerine herkesin üzerine biniyor. GitHub şu an SHA-256 depoları barındıramıyor; HN yorumcularının özel beta aşamasında olduğunu söylediği bu eksikliği Chacon muhtemelen 3.0'ı geciktiren ana neden olarak görüyor. Code forge'lara format seçicileri gerekecek, 40 karakterlik hash varsayan her betik ve pipeline güncellenmek zorunda kalacak ve Git'in bir kütüphane olarak gömülmesi zor olduğundan araç ekosisteminin büyük bölümü onu baştan, az SHA-256 desteğiyle yeniden uyguluyor. Mevcut bir projeyi dönüştürmek ayrıca imzaları ve eski hash'leri gömen geçmiş bağlantıları geçersiz kılacak.

Onun alternatifi, SHA-1'i yalnızca bir veritabanı anahtarı olarak tutmak ve tüm ağacın bağımsız, imzalı bir hash'ini ek bir başlık olarak eklemek. Kavram kanıtı, 1,5 GB'lık Linux çekirdeği ağacını 257 ms'de, Git'in kendi ağacını 17 ms'de sağlamlaştırdı ve Chacon, SHA-1 artık hiçbir şeyi korumadığı için bunun SHA-1'in koruyucu bir algoritma olarak 2030'da emekliye ayrılmasına ilişkin NIST kararına da yanıt verdiğini savunuyor.

Git projesi neden yine de geçiyor

Projenin açıkladığı gerekçe bir olay değil, bir zaman çizelgesi. Dokümantasyon, SHA-1'in NIST tarafından kullanımdan kaldırılmasına ve mevcut seçilen-önekli saldırılara atıf yapıyor, donanım ucuzladıkça daha fazla saldırı bekliyor ve hamleyi bir bozulmaya tepki değil, henüz yıllarlık bir süre varken yapılan bir hazırlık olarak çerçeveliyor.

Ancak Chacon'un alternatifinde bir boşluk var ve dev.to yazısı bunu ortaya çıkaran HN tartışmasına atıf yapıyor: ağaç içeriği üzerinden yapılan ikinci bir hash dosyaları doğrular ama geçmişi doğrulamaz. Commit grafikleri hash referanslarından oluşan zincirlerdir; bu yüzden sahte bir soy, bir commit'in neyin üzerine inşa edildiğini iddia ettiğini yeniden yapılandırabilir. Chacon'un şemasının başlığı taşıyan nesneleri, her commit'i değil, kapsadığını kabul ettiği bildiriliyor.

Resmi geçiş tasarımı da eleştirinin ima ettiğinden daha yumuşak. SHA-1 ve SHA-256 adları arasında çift yönlü bir eşleme tanımlıyor; böylece dokümantasyon, bağlantı ve imzalardaki eski hash'ler çözülebilir kalıyor ve dönüştürülmüş depolar SHA-1 remote'larla birlikte çalışabiliyor. Bir HN test kullanıcısı, SHA-1 submodule'lerin mevcut Git'te zaten SHA-256 bir üst depo içinde çalıştığını gördü.

Neden önemli

dev.to yazarının kendi anekdotu yüksek payı ortaya koyuyor: eski bir servisi Bitbucket Server'dan GitHub'a taşımasına yardım ettikten sonra yapılan bir post-mortem, ekibin CI betiklerinin yarısının commit hash'lerini 40 karakterlik bir regex ile ayrıştırdığını ortaya çıkardı ve her örneği bulmak tam bir gün aldı. Git 3.0 çıktığında her git init, eski araçların boğulabileceği bir depo üretecek; bu yüzden takımların varsayılan değişmeden önce pipeline'larını sabit uzunluktaki hash varsayımları açısından denetlemesi akıllıca olur. Bozulmanın ötesinde, bu tartışma, versiyon kontrolün omurgasının güven modelini nasıl göç ettireceğine dair çözümsüz bir tartışma: her depoyu yeniden anahtarlamak mı, yoksa elindeki anahtarlara daha güçlü doğrulama eklemek mi.