Esperando con ganas Git 2.56 — y 3.0

Artículo original ↗ Discusión en Hacker News ↗

Los planes para Git 2.56 y un eventual 3.0 están generando debate sobre cómo migrar de SHA‑1 a SHA‑256 sin romper el historial, las herramientas ni las firmas, y cómo verificar la integridad durante esa transición. Los comentaristas también evalúan los beneficios y compensaciones de introducir Rust para partes internas más seguras, adoptar nuevos mecanismos de almacenamiento como reftable y backends intercambiables en lugar de refs basadas en el sistema de archivos, y mejorar problemas de usabilidad de larga data como los estilos de conflicto, los valores por defecto y el soporte de change IDs. También surgen preguntas más amplias de seguridad, incluida la relación entre las elecciones de hash y las amenazas cuánticas, y si los cambios incrementales mejoran de verdad la seguridad en una gran base de código en C.

Migración a SHA-256 y reescritura del historial

  • Varios comentarios debaten si pasar de SHA-1 a SHA-256 exige force-pushes y reescrituras del historial.
  • Preocupaciones: riesgo de manipulación del historial durante pushes forzados; invalidación de referencias basadas en SHA en issues, comentarios y código; rotura de clones superficiales; invalidación de firmas de commits existentes.
  • Algunos señalan que los blobs de contenido no cambian, así que se puede volver a calcular y comparar historiales SHA-1 frente a SHA-256, pero eso no evita la corrupción del historial.
  • Otros destacan que Git no mezclará libremente repositorios SHA-1 y SHA-256 (por ejemplo, submódulos), lo que implica configuraciones de doble repositorio de larga duración y tablas de mapeo.
  • La documentación sugiere que el cambio se parece más a un repack con capas de compatibilidad y tablas de búsqueda, no solo a un corte brusco.

Adopción de Rust en Git

  • Un lado sostiene que Rust se está imponiendo sin necesidad y que una pequeña parte en Rust no mejora de forma significativa la seguridad.
  • Otros responden que:
    • Las mejoras incrementales importan, especialmente para código nuevo y analizadores, donde C tiene una larga historia de CVEs de seguridad de memoria.
    • Usar lenguajes más seguros para componentes nuevos es razonable, aunque el C heredado permanezca.
  • Hay debate sobre enfoques alternativos de “C seguro” (por ejemplo, Fil-C), señalando compensaciones en rendimiento y memoria.

Backends de almacenamiento, refs y reftable

  • Algunos quieren que Git “abandone los archivos lentos” y use “una base de datos de verdad”.
  • Réplica: el sistema de archivos ya es una base de datos no relacional; los problemas de rendimiento vienen de casos de uso más recientes (muchas refs, flujos de trabajo estilo hub).
  • Se está trabajando en backends intercambiables (reftable para refs; almacenes de objetos alternativos como SQLite, S3, etc.).
  • Se elogia reftable por resolver problemas de nombres/rutas de refs y problemas de sensibilidad a mayúsculas, pero preocupa la compatibilidad con herramientas (por ejemplo, libgit2, integraciones de shell).

Valores por defecto, UX y características de flujo de trabajo

  • Se pide que Git 3.0 corrija “malos valores por defecto”, incluyendo:
    • Valores de push más seguros (--force-with-lease, configuración automática del remoto).
    • Mejor estilo de conflictos (zdiff3), mejores diffs y recursión de submódulos, y rerere activado.
  • Algunos proponen “change IDs” estandarizados para commits (como los usados por Gerrit, jj, GitButler) para admitir revisión por commit, cambios apilados e IDs estables a través de rebases; los comandos actuales de Git a menudo eliminan esos encabezados.
  • Varias opiniones sobre el “snapshotting simple”: usar git stash, ramas/tags WIP dedicadas o herramientas externas de snapshotting.

Seguridad y preocupaciones cuánticas

  • La discusión aclara que:
    • Los ataques de extensión de longitud no son relevantes para el uso de hashes en Git.
    • Las amenazas cuánticas afectan sobre todo a la criptografía asimétrica; los cifrados simétricos y los hashes como mucho ven una reducción de seguridad de raíz cuadrada.
  • SHA-256 se considera suficiente; cambiar ahora a SHA-3 se ve como impráctico dado el largo trabajo de transición ya realizado.

Varios

  • Notas sobre GitHub y Bitbucket rezagados en el soporte de SHA-256, aunque GitHub supuestamente tiene vistas previas privadas.
  • Interés en que reftable se convierta en el valor por defecto, además de debates secundarios sobre IDs de commit enteros (como en Mercurial) y comportamientos de caída del sistema de archivos que afectan a las refs.