El próximo valor predeterminado SHA-256 de Git 3.0 será un error costoso
El movimiento planificado de Git en la versión 3.0 de SHA‑1 a SHA‑256 como formato de hash predeterminado está generando preocupación de que el cambio fragmente el ecosistema y rompa décadas de herramientas, referencias y flujos de trabajo que dependen de IDs de commits de 40 caracteres. Los críticos argumentan que las debilidades de SHA‑1 son en gran medida teóricas para el modelo de amenazas real de Git y que los hashes más fuertes deberían añadirse como un mecanismo adicional de integridad o firma, en lugar de reemplazar el formato central de ID de una forma incompatible. Los defensores de la migración replican que la seguridad de los hashes ya es un requisito regulatorio y de la cadena de suministro, pero existe una preocupación amplia de que el camino elegido se parezca a transiciones dolorosas pasadas como Python 2→3, especialmente en submódulos, sistemas de CI y repositorios corporativos de larga vida.
¿Qué tan grave es la inseguridad de SHA‑1?
- Muchos sostienen que SHA‑1 ya está “roto” (colisiones de prefijo elegido, Shambles, etc.) y que depender de él para integridad o firmas no es seguro.
- Otros dicen que los ataques prácticos contra repositorios reales de Git siguen siendo extremadamente difíciles, especialmente dado el formato de objetos de Git y la detección de colisiones
sha1dc, y que los ataques más probables a la cadena de suministro llegan por compromiso de mantenedores o de la infraestructura, no por hashes. - Hay desacuerdo sobre si los hashes de Git son “seguridad” o solo identificadores de consistencia; algunos señalan que firmar commits y fijarlos por hash implícitamente los vuelve críticos para la seguridad.
Impacto de convertir SHA‑256 en el valor predeterminado
- Quienes lo apoyan: eventualmente SHA‑1 debe retirarse; retrasarlo solo empeora un cambio futuro. Los valores predeterminados deben cambiar o nadie se moverá.
- Críticos: cambiar el valor predeterminado crea dos tipos de repositorios incompatibles, lo que provoca confusión, herramientas rotas que asumen hashes de 40 caracteres y fallos difíciles de depurar para usuarios que no entienden los formatos. Muchos lo comparan con migraciones a IPv6 o Python 3.
Submódulos, herramientas y compatibilidad del ecosistema
- Un temor importante es la ruptura de submódulos: antes se describían como no compatibles padres SHA‑1 con submódulos SHA‑256 (y viceversa).
- Un comentarista muestra experimentalmente que los submódulos SHA‑1 funcionan dentro de un repositorio SHA‑256 en Git reciente, pero las garantías a largo plazo y los casos extremos siguen sin estar claros.
- Ecosistemas grandes (Yocto, Nix, CI/CD, gestores de paquetes de lenguajes) dependen de hashes de commits; las reescrituras globales del historial invalidarían referencias en configuraciones, documentación, rastreadores de incidencias, etc.
Forjas y UX (GitHub, GitLab, autoalojado)
- Preocupa que las forjas expongan a los usuarios opciones de formato que no entienden, o que gestionen mal la autodetección en el primer push.
- Otros replican que los servidores pueden inferir el formato a partir del primer push y que el plan documentado de transición de hashes de Git incluye mapeo SHA‑1↔SHA‑256 para interoperabilidad.
Diseños y propuestas alternativas
- Sugerencias populares:
- Guardar ambos hashes por objeto (o encabezados separados de hash de “confianza del árbol”) mientras se mantienen estables los IDs SHA‑1 para direccionamiento.
- Usar digests autorreferenciales al estilo multihash o permitir múltiples algoritmos en un mismo repositorio como hace Fossil.
- Mantener SHA‑1 como predeterminado; añadir SHA‑256 solo donde la seguridad o la política lo exijan.
- Los opositores señalan que mezclar fortalezas de hash puede degradar la seguridad global y complicar la implementación.
Modelos de seguridad y preguntas abiertas
- Debate sobre rutas de ataque realistas: contrabando de código basado en colisiones frente a ataques sociales o de infraestructura más simples.
- Algunos ven la migración como una higiene necesaria y una preparación para el futuro; otros la ven como una costosa “teatralidad de seguridad”.
- Para muchos sigue sin estar claro qué garantías exactas ofrecerá Git 3.0 para búsquedas SHA‑1, interoperabilidad de submódulos y preservación de referencias externas existentes.