Recientemente encontré una publicación del 29/04/2013 en un grupo de discusión de BSD en
http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html
donde el cartel dice:
Me encontré con una colisión de hash una vez, usando git rebase.
Lamentablemente, no proporciona pruebas de su reclamo. Pero tal vez le gustaría tratar de contactarlo y preguntarle sobre este supuesto incidente.
Pero en un nivel más general, debido al ataque de cumpleaños, la posibilidad de una colisión de hash SHA-1 es 1 en pow (2, 80).
Esto suena mucho y ciertamente es mucho más que el número total de versiones de archivos individuales presentes en todos los repositorios Git del mundo combinados.
Sin embargo, esto solo se aplica a las versiones que realmente permanecen en el historial de versiones.
Si un desarrollador confía mucho en el rebase, cada vez que se ejecuta un rebase para una rama, todos los commits en todas las versiones de esa rama (o parte de la rama) obtienen nuevos hashes. Lo mismo es cierto para cada archivo modificado con "git filter-branch". Por lo tanto, "rebase" y "filter-branch" pueden ser grandes multiplicadores para la cantidad de hashes generados a lo largo del tiempo, aunque no todos se guarden realmente: Frecuentemente, después de rebase (especialmente con el propósito de "limpiar" una rama ), la rama original se descarta.
Pero si la colisión ocurre durante el rebase o la ramificación del filtro, aún puede tener efectos adversos.
Otra cosa sería estimar el número total de entidades hash en repositorios git y ver qué tan lejos están de pow (2, 80).
Digamos que tenemos alrededor de 8 mil millones de personas, y todas ellas estarían ejecutando git y mantendrían sus cosas versionadas en 100 repositorios git por persona. Supongamos además que el repositorio promedio tiene 100 confirmaciones y 10 archivos, y solo uno de esos archivos cambia por confirmación.
Para cada revisión tenemos al menos un hash para el objeto del árbol y el objeto de confirmación en sí. Junto con el archivo modificado, tenemos 3 hashes por revisión y, por lo tanto, 300 hashes por repositorio.
Para 100 repositorios de 8 mil millones de personas, esto proporciona pow (2, 47) que todavía está lejos de pow (2, 80).
Sin embargo, esto no incluye el supuesto efecto de multiplicación mencionado anteriormente, porque no estoy seguro de cómo incluirlo en esta estimación. Tal vez podría aumentar considerablemente las posibilidades de una colisión. Especialmente si los repositorios muy grandes que tienen un largo historial de confirmaciones (como el Kernel de Linux) son modificados por muchas personas para pequeños cambios, que sin embargo crean diferentes hashes para todas las confirmaciones afectadas.
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.
, fuente: lwn.net/Articles/307281