Saya baru-baru ini menemukan posting dari 2013-04-29 di grup diskusi BSD di
http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html
tempat poster mengklaim:
Saya bertemu tabrakan hash sekali, menggunakan git rebase.
Sayangnya, dia tidak memberikan bukti untuk klaimnya. Tapi mungkin Anda ingin mencoba menghubunginya dan bertanya kepadanya tentang kejadian yang seharusnya terjadi.
Tetapi pada tingkat yang lebih umum, karena serangan ulang tahun, peluang untuk tabrakan hash SHA-1 adalah 1 pow (2, 80).
Ini kedengarannya banyak dan tentu saja jauh lebih dari jumlah total versi file individual yang ada di semua repositori Git di dunia yang digabungkan.
Namun, ini hanya berlaku untuk versi yang benar-benar tetap dalam riwayat versi.
Jika pengembang sangat bergantung pada rebasing, setiap kali rebase dijalankan untuk cabang, semua komit dalam semua versi cabang itu (atau bagian yang diremajakan dari cabang) mendapatkan hash baru. Hal yang sama berlaku untuk setiap file yang dimodifikasi dengan "git filter-branch". Oleh karena itu, "rebase" dan "filter-branch" mungkin merupakan pengganda besar untuk jumlah hash yang dihasilkan dari waktu ke waktu, meskipun tidak semua dari mereka benar-benar disimpan: Sering, setelah rebasing (terutama untuk tujuan "membersihkan" cabang ), cabang asli dibuang.
Tetapi jika tabrakan terjadi selama rebase atau filter-cabang, itu masih dapat memiliki efek buruk.
Hal lain adalah memperkirakan jumlah total entitas hash dalam repositori git dan melihat seberapa jauh mereka dari pow (2, 80).
Katakanlah kita memiliki sekitar 8 miliar orang, dan semuanya akan menjalankan git dan menyimpan versi mereka dalam 100 repositori git per orang. Mari kita asumsikan repositori rata-rata memiliki 100 commit dan 10 file, dan hanya satu dari file-file itu yang berubah per komit.
Untuk setiap revisi kita memiliki setidaknya hash untuk objek tree dan objek commit itu sendiri. Bersama dengan file yang diubah, kami memiliki 3 hash per revisi, dan dengan demikian 300 hash per repositori.
Untuk 100 repositori dari 8 miliar orang ini memberikan pow (2, 47) yang masih jauh dari pow (2, 80).
Namun, ini tidak termasuk efek multiplikasi yang seharusnya disebutkan di atas, karena saya tidak yakin bagaimana memasukkannya dalam estimasi ini. Mungkin itu bisa meningkatkan kemungkinan tabrakan. Terutama jika repositori yang sangat besar yang sejarah komitnya panjang (seperti Kernel Linux) diubah oleh banyak orang untuk perubahan kecil, yang tetap membuat hash yang berbeda untuk semua komit yang terpengaruh.
I've been informed by the git Gods that the chances of a SHA1 collision is the same as the Earth being sucked up into the black hole created by the CERN accelerator. If this is indeed true, then there's no need for that extra memcmp.
, sumber: lwn.net/Articles/307281