git: la distro traía un git que NO PODÍA CLONAR — sha1dc leía desalineado y ubsan lo abortaba

Encontrado intentando que la caja de producción clonara el repo para ser un hub de verdad
(SDD 28 §6.11). `git ls-remote` funciona; `git clone` —de cualquier repo, incluso `--depth 1`— muere:

    fatal: fetch-pack: invalid index-pack output

El informe completo, que la traza corta escondía:

    panic: load of misaligned address 0x… for type 'const uint32_t',
           which requires 4 byte alignment
      in sha1_compression_states → sha1_process → SHA1DCUpdate → git_SHA1DCUpdate
      → git_hash_update → unpack_entry_data → cmd_index_pack

Dos cosas, y las dos son de fondo:

1. **`-fsanitize=undefined` estaba en CFLAGS**, no sólo en LDFLAGS. El motivo original era legítimo
   —las `libz.a` etc. materializadas traen referencias `__ubsan_handle_*` que bajo `-static` no se
   resuelven solas, y el flag AL ENLAZAR trae el runtime de zig— pero en CFLAGS **instrumenta el
   código de git**. Un arreglo de ENLACE se había vuelto una mina en RUNTIME, y justo en la ruta de
   hash, que es por donde pasa todo lo que git recibe. Ahora va sólo en LDFLAGS.

2. **`-DSHA1DC_FORCE_ALIGNED_ACCESS`**, que es la causa real. `sha1collisiondetection` —el backend
   SHA1 por defecto, el que detecta SHAttered— lee palabras de 32 bits SIN alinear. En x86 eso
   funciona y por eso nadie lo nota nunca; según el estándar es UB, y basta con que el runtime ubsan
   esté enlazado para que aborte. El define hace que lea byte a byte: quita el UB en la FUENTE en vez
   de esconderlo. Sin él, cualquier build que arrastre el runtime vuelve a romper `clone`.

Probado: `git clone --depth 1` del propio repo desde la caja ⇒ **877 recetas, commit 543676e1**.
Antes fallaba con y sin `--depth`.

Radio cero: `git` no es dep de ninguna receta (medido). Pero SÍ es raíz de `perfil.base`, así que
esto arregla la distro entera, no sólo el hub.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x

recipes/git.toml

@@ -26,14 +26,45 @@ flags    = []
 # gettext/tcltk/python (no los tenemos); curl/openssl/pcre2/zlib resuelven por las
 # deps materializadas en /usr del lab.
 # Flags idénticas en compile e install: git graba CFLAGS/LDFLAGS en GIT-CFLAGS y
-# fuerza relink si difieren entre invocaciones. -fsanitize=undefined enlaza el
-# runtime ubsan de zig (la libz.a/etc. materializadas traen __ubsan_handle_* que
-# bajo -static no se resuelven solas).
+# fuerza relink si difieren entre invocaciones.
+#
+# ⚠⚠ `-fsanitize=undefined` VA SÓLO EN LDFLAGS, NUNCA EN CFLAGS. Estaba en los dos, y el motivo era
+# legítimo —las libz.a/etc. materializadas traen referencias `__ubsan_handle_*` que bajo `-static` no
+# se resuelven solas, y el flag al enlazar trae el runtime ubsan de zig—. Pero en CFLAGS **instrumenta
+# el código de git**, y el resultado era un git que NO PUEDE CLONAR:
+#
+#     $ git clone --depth 1 <cualquier repo>
+#     ???:?:?: 0x188db5e in git_hash_sha1_update
+#     ???:?:?: 0x1353318 in parse_pack_objects
+#     fatal: fetch-pack: invalid index-pack output
+#
+# `ls-remote` funciona (no desempaqueta nada), así que el fallo parece de red y no de git. Medido el
+# 2026-09-11 en la caja de producción (SDD 28 §6.11); el binario sellado traía 69 cadenas de ubsan.
+# Un arreglo de ENLACE se había convertido en una mina en RUNTIME, en la ruta de hash, que es por
+# donde pasa todo lo que git recibe.
+#
+# La distinción que hay que conservar: el runtime hace falta (LDFLAGS), la instrumentación no
+# (CFLAGS). Si algún día hay que volver a instrumentar, que sea una receta aparte.
+#
+# ⚠ Y `-DSHA1DC_FORCE_ALIGNED_ACCESS`, que es LA causa de fondo. El informe completo dice:
+#
+#     panic: load of misaligned address 0x… for type 'const uint32_t',
+#            which requires 4 byte alignment
+#       in sha1_compression_states → sha1_process → SHA1DCUpdate → git_SHA1DCUpdate
+#       → git_hash_update → unpack_entry_data → cmd_index_pack
+#
+# `sha1collisiondetection` —el backend de SHA1 por defecto de git, el que detecta el ataque
+# SHAttered— lee palabras de 32 bits SIN alinear. En x86 eso funciona y por eso nadie lo nota; según
+# el estándar es comportamiento indefinido, y basta que el runtime ubsan esté enlazado para que
+# ABORTE. El define hace que sha1dc lea byte a byte: quita el UB en la FUENTE en vez de esconderlo.
+#
+# Las dos cosas juntas importan: sin el define, cualquier build que arrastre el runtime ubsan vuelve
+# a romper `git clone` — y `clone` es por donde pasa todo lo que git recibe.
 compile = '''
 make prefix=/usr CC="${CC:-cc}" \
 	NO_GETTEXT=1 NO_TCLTK=1 NO_PYTHON=1 NO_INSTALL_HARDLINKS=1 \
 	NO_R_TO_GCC_LINKER=1 FUZZ_PROGRAMS= \
-	CFLAGS="$CFLAGS -static -fsanitize=undefined" \
+	CFLAGS="$CFLAGS -static -DSHA1DC_FORCE_ALIGNED_ACCESS" \
 	LDFLAGS="$LDFLAGS -static -fsanitize=undefined" \
 	all
 '''
@@ -41,7 +72,7 @@ install = '''
 make prefix=/usr DESTDIR="/out" CC="${CC:-cc}" \
 	NO_GETTEXT=1 NO_TCLTK=1 NO_PYTHON=1 NO_INSTALL_HARDLINKS=1 \
 	NO_R_TO_GCC_LINKER=1 FUZZ_PROGRAMS= \
-	CFLAGS="$CFLAGS -static -fsanitize=undefined" \
+	CFLAGS="$CFLAGS -static -DSHA1DC_FORCE_ALIGNED_ACCESS" \
 	LDFLAGS="$LDFLAGS -static -fsanitize=undefined" \
 	install
 '''