Files
takana/recipes/git.toml
T
SergioandClaude Opus 5 ae1b0c9fe8 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
2026-09-11 12:49:30 +00:00

84 lines
4.0 KiB
TOML

# Importada de Alpine aports por `takana import-alpine` (Etapa G). PUNTO DE PARTIDA — pero
# YA trae los parches de musl de Alpine (lo que un import de nix pierde). Pendiente: el
# sha256 del tarball (el wrapper lo calcula), y adaptar build/install del shell de abuild.
name = "git"
version = "2.54.0"
license = "GPL-2.0-only"
[source]
tarball = "https://www.kernel.org/pub/software/scm/git/git-2.54.0.tar.xz"
# FIXME sha256: el wrapper lo calcula (Alpine publica sha512). sha512 de Alpine:
# sha512 = "cb363917124edc245c9f6745e6e0c4093990275b4d57f9d2213c655b304ac81b05ece8d88546122727495ebc48a5ae19ab166a3ee43b6b8c68da488ac0270064"
sha256 = "f689162364c10de79ef89aa8dbf48731eb057e34edbbd20aca510ce0154681a3"
patches = ["fix-t4219-with-sticky-bit.patch"]
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "static"
# Split de la info de depuración (SDD 23 etapa 4, tanda de HOJAS). Entra en `hash_inputs`.
strip_debug = true
flags = []
[build.phases]
# build de git LIMPIO estático-musl: Makefile propio (no autotools). Desactivamos
# 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` 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 -DSHA1DC_FORCE_ALIGNED_ACCESS" \
LDFLAGS="$LDFLAGS -static -fsanitize=undefined" \
all
'''
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 -DSHA1DC_FORCE_ALIGNED_ACCESS" \
LDFLAGS="$LDFLAGS -static -fsanitize=undefined" \
install
'''
# depends de runtime de Alpine (NO build-deps): perl
[deps]
build = ["binutils", "zlib", "openssl", "curl", "pcre2", "linux-headers", "perl"]