El SHA-256 por defecto de Git 3.0 es un error costoso, dice Chacon

Scott Chacon dice que el plan de Git de convertir SHA-256 en el hash por defecto de los repositorios nuevos en la versión 3.0 será un error costoso. Su argumento, publicado en el blog de GitButler el 30 de septiembre de 2026, llega mientras el propio proyecto Git dice que el cambio esperará a que el ecosistema esté listo. La disputa importa porque toda herramienta que almacena o analiza un identificador de commit de Git se ve afectada por la respuesta.

Tech AI Wire cubrió el plan de Git 3.0 en septiembre. Los repositorios nuevos tendrán nombres de objeto SHA-256, el formato reftable y una rama main, y compilar Git exigirá Rust.

Qué sostiene Chacon

Git identifica cada archivo, carpeta y commit mediante un hash, una huella de longitud fija calculada a partir de su contenido. Git ha usado el algoritmo SHA-1 para ello desde el principio. Se sabe que SHA-1 es débil. Con suficiente esfuerzo, los investigadores pueden producir dos entradas distintas con la misma huella, lo que se llama una colisión.

La tesis de Chacon es que esta debilidad es teórica para Git. No se ha documentado ninguna colisión en miles de millones de repositorios de Git, escribe, a pesar de los fallos matemáticos conocidos de SHA-1.

Después enumera el coste. Un repositorio SHA-256 rompe todos los hashes SHA-1 existentes. Las URL, las referencias a commits en los gestores de incidencias y cualquier otra cosa que cite un identificador de 40 caracteres dejan de coincidir. La mayoría de las implementaciones de bibliotecas de Git, dice, carecen de soporte completo para SHA-256.

Su alternativa es verificar la integridad sin cambiar los nombres de objeto. Chacon informa de que calcular el hash de un árbol completo ya extraído es rápido. Sus pruebas tardaron unos 5 segundos en el árbol de Chromium, de 35 GB y 2,1 millones de archivos, y 257 milisegundos en el núcleo Linux, de 1,5 GB. Propone incrustar sumas de verificación SHA-256 en objetos firmados, junto a los nombres SHA-1. Un proyecto podría entonces verificar con el hash más fuerte sin partir el ecosistema en dos. Señala git-evtag, una herramienta de 2015, como antecedente de la idea.

Qué dice el proyecto Git

El propio documento de cambios incompatibles de Git describe el plan al que Chacon se opone. Git 3.0 cambia el hash por defecto a SHA-256 solo para los repositorios recién inicializados. Los repositorios SHA-1 existentes siguen funcionando, y el documento dice que no hay planes de retirar el formato de objetos SHA-1.

El documento también explica por qué el proyecto quiere el cambio. Califica SHA-1 de criptográficamente roto y enumera las pruebas.

Hito	Año
El NIST declara obsoleto SHA-1	2011
Ataque SHAppening	2015
Colisión SHAttered	2017
Git elige SHA-256 como sucesor	finales de 2018
Ataque de cuasi colisión de cumpleaños	2019
Ataque Shambles	2020

Dos puntos del documento juegan a favor de Chacon. El proyecto Git dice que no hará el cambio hasta que las bibliotecas, las plataformas de alojamiento y las aplicaciones de terceros demuestren estar listas para SHA-256. Y no fija ninguna fecha de lanzamiento para Git 3.0. Informaciones anteriores situaban el lanzamiento hacia finales de 2026; el documento en sí no da fecha.

Cómo está pensada la transición

El diseño de la transición de función hash de Git muestra que el proyecto ha pensado en la interoperabilidad. La elección de SHA-256 data de finales de 2018. El diseño permite que cada repositorio migre a su propio ritmo. Un repositorio SHA-256 mantiene una tabla de traducción en ambos sentidos, de modo que un objeto puede referenciarse con cualquiera de los dos hashes durante la transición.

Las operaciones de red también están cubiertas. El diseño describe push y fetch entre servidores SHA-256 y SHA-1, convirtiendo los objetos al empaquetarlos. Los commits pueden llevar dos firmas, una en el campo existente gpgsig y otra en un nuevo campo gpgsig-sha256. El trabajo se divide en cinco fases y termina con una transición completa una vez que hayan migrado suficientes repositorios. Quedan dos límites: los clones superficiales y los alternates no funcionan entre repositorios SHA-1 y SHA-256.

La diferencia visible es la longitud. Un nombre de objeto SHA-1 tiene 40 caracteres hexadecimales. Un nombre SHA-256 tiene 64.

Qué significa esto para los desarrolladores

Hoy no cambia nada para ti. Git 3.0 no tiene fecha de lanzamiento, y los repositorios existentes se quedan en SHA-1 de todos modos. La cuestión es qué hacer antes de que llegue un nuevo valor por defecto, sea cuando sea.

Primero, prueba ya tus herramientas contra un repositorio SHA-256. La afirmación de Chacon de que la mayoría de las bibliotecas de Git carecen de soporte completo se puede comprobar. Crea un repositorio de prueba en modo SHA-256 y ejecuta contra él tus scripts de integración continua, tus hooks de despliegue y tus integraciones de revisión de código.

Segundo, audita todo lo que presuponga un identificador de 40 caracteres. Las columnas de base de datos, las expresiones regulares y los patrones de URL que fijan esa longitud truncarán o rechazarán los nombres de 64 caracteres. Nuestro artículo de septiembre señalaba lo mismo. La entrada de Chacon recuerda que la rotura se extiende a cada enlace almacenado.

Tercero, valora su alternativa por sus méritos. Si tu preocupación es detectar manipulaciones y no el nombrado, las sumas de verificación firmadas sobre el árbol lo ofrecen hoy sin cambiar de formato. Si necesitas nombres de objeto SHA-256, el diseño de la transición ya admite una migración por repositorio con interoperabilidad SHA-1. No tienes que esperar a la 3.0.

Por último, fíjate en la prueba de preparación del proyecto y no en el número de versión. El documento de cambios incompatibles vincula el cambio del valor por defecto a la preparación del ecosistema. Eso significa que son las forjas y las bibliotecas, no el calendario de lanzamientos de Git, las que deciden cuándo ocurre.