Estaba picando el feed de Hacker News como todos los días antes de que empiece la pega, cuando me topé con algo rarísimo: Scott Chacon, cofundador de GitHub y el mismo que escribió Pro Git, sacó un post titulado «Git 3.0’s upcoming SHA-256 default will be a costly mistake». Traducción libre: la próxima versión de Git va a cambiar el algoritmo de hash por defecto, de SHA-1 a SHA-256, y él está en contra. Alguien del club fundacional del control de versiones moderno pidiendo frenar a su propio bebé. Eso, por sí solo, ya valía la lectura.
De qué va la cosa
Git usa hashes SHA-1 como llaves de todos sus objetos: archivos, árboles, commits. Literalmente todo el historial está encadenado por ahí. Como SHA-1 acumula ataques teóricos de colisión desde 2017, la decisión del proyecto fue moverse a SHA-256 en la versión 3.0 y partir limpio. Suena razonable. El punto de Chacon es que ese cambio va a partir el ecosistema en dos: los repos nuevos van a nacer con SHA-256 y los antiguos van a seguir en SHA-1, sin que se puedan mezclar de forma directa.
La consecuencia práctica: un git init con la versión nueva va a crear repos que no se pueden subir a cualquier forja sin configurar el formato explícitamente. Los submódulos solo van a aceptar otros submódulos del mismo formato, así que una librería popular va a necesitar mantener dos variantes para servir a las dos mitades. Y todo link, script o tooling intermedio que asume hashes de 40 caracteres va a quebrar. No es un cambio de librería, es una bifurcación global.
El argumento que más me pegó
Lo importante del post no es el terror a los hashes, es la separación de conceptos. Chacon cita algo que dijo Linus Torvalds en 2005, en pleno nacimiento de Git: la verdadera seguridad no está en el hash, está en la distribución. O sea, confiamos o no confiamos en un código porque sabemos de dónde lo bajamos, no porque el hash del contenido sea matemáticamente más fuerte.
Si tu amenaza real es que un atacante meta código malicioso en tu proyecto, no necesita gastar fortunas en GPUs para fabricar una colisión criptográfica. Basta con comprar o hackear al mantenedor de un paquete npm popular y meter el malware por la vía fácil. Eso ya lo vimos con xz en 2024 y con una pila de incidentes parecidos. El hash es un detallito al lado de la cadena de suministro.
Chacon propone otra vía para el 1% de los proyectos que sí necesitan esa capa extra: firmar los tags con un segundo hash independiente, tipo SHA-256 o BLAKE3, calculado sobre el árbol de contenido por fuera del modelo de hashes de Git. Existe incluso una implementación de esta idea desde 2015, git-evtag, y según el post, para el árbol completo de Chromium con submódulos tarda solo 5 segundos en calcularse. Nada despreciable.
Mi opinión, con el corazón en la infra
Yo administro un cluster con bastantes VPS, deployo con Docker, tengo scripts que parsean Git, pipelines de CI que ejecutan git pull, y una infinidad de automatizaciones que dependen de la estabilidad del formato interno de Git. Si Git 3.0 parte el mundo en dos, mis scripts y mis repos van a tener que ser auditados, migrados o replantados. No es gratis.
Pero más que el costo, me impresionó la lección criptográfica: la integridad no es lo mismo que la confianza. Uno tiende a pensar que un hash más fuerte significa más seguridad, pero si la amenaza real no es matemática, gastar esfuerzo en reemplazar el hash no soluciona nada. Y eso aplica a todo, no solo a Git. Pasa con los certificados, con las contraseñas, con la infraestructura de firmas. Uno reemplaza primitivas por miedo a un ataque teórico, mientras deja abierta la puerta por donde de verdad están entrando los atacantes.
Como alguien que estudia ciberseguridad y vive pegado a servidores, la lección es directa: antes de meterse en una migración grande, pregúntate cuál es el vector de ataque real contra tu sistema en particular, no el vector teórico contra el estándar. A veces el fix criptográficamente elegante es la peor decisión de infra. Git 3.0 va a ser un caso de estudio prontito.
Fuente del tema: Git 3.0’s upcoming SHA-256 default will be a costly mistake, del blog de GitButler.
Fuente de inspiración: Git 3.0’s upcoming SHA-256 default will be a costly mistake
