From 1728fd65e5bd49ffaf794d55f7202cf7225b08d8 Mon Sep 17 00:00:00 2001 From: Sergio Date: Sat, 5 Sep 2026 08:50:17 +0000 Subject: [PATCH] =?UTF-8?q?firefox=20NO=20reproduce=20bit=20a=20bit:=20el?= =?UTF-8?q?=20BuildID=20es=20la=20fecha=20del=20build=20=E2=80=94=20medido?= =?UTF-8?q?=20y=20anotado,=20no=20arreglado=20de=20paso?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Al abrir `application.ini` para el branding de atuq apareció esto: BuildID=20260905035306 Es la fecha y hora del build. Dos construcciones de la MISMA receta, con el mismo ArtifactHash, producen bytes distintos. Es justo el agujero que el invariante de reproducibilidad existe para cerrar, y no se ve en `build-state.json` porque el hash es input-addressed y no se mueve por esto. El arreglo es conocido y lo usa Alpine: exportar `MOZ_BUILD_DATE` con un valor determinista. NO se aplica de paso, a propósito: vive en una FASE, así que re-hashea la receta y cuesta otro build de cuatro horas más el re-sellado de atuq, que cuelga de ella. Es su propia unidad de trabajo y queda como 4.c en el plan del SDD 26. El comentario se comprobó que NO mueve el hash antes de commitearlo (b3:aa90192a antes y después): un comentario fuera de las fases no entra en `hash_inputs`, así que el firefox sellado sigue válido. Y el §2.ter del SDD queda con el estado real de atuq v0.2 y su evidencia. --- docs/26-atuq-envoltorio-gecko.md | 15 ++++++++++++--- recipes/firefox.toml | 10 ++++++++++ 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md index 11f73f14..27e23d09 100644 --- a/docs/26-atuq-envoltorio-gecko.md +++ b/docs/26-atuq-envoltorio-gecko.md @@ -282,8 +282,16 @@ bytes. Editar un CSS del overlay mueve el `ArtifactHash`; renombrar el directori Un `.swm` **no** puede llevar una receta derivada, y los cuatro sitios que lo tocan fallan diciéndolo: el manifiesto es compartible y necesita un puntero resoluble desde fuera. -**Hecho el 2026-09-05** (commit `aeebb19`): `recipes/atuq.toml` + `recipes/atuq/`, hash -`b3:2d6e4dcf`. La capa son cuatro ficheros —autoconfig, `atuq.cfg`, `chrome/atuq.css`, +**Hecho el 2026-09-05** (commits `aeebb19` y `6f6c32b`): `recipes/atuq.toml` + `recipes/atuq/`. +La **v0.2** (`b3:7eff4ba4`) ya trae el branding: `application.ini` (Vendor/Name/RemotingName/ +CodeName, con el `ID` intacto para no salirse del ecosistema de complementos), `brand.ftl` dentro de +`browser/omni.ja`, los binarios renombrados, iconos propios y `.desktop`. El re-empaque preserva +orden, `STORED` y fechas del original, y se verificó contra el artefacto: **5306 entradas, mismo +orden, y una sola con contenido distinto**. El `BuildID` se deriva del contenido del overlay —no de +la fecha— porque es la clave con la que Gecko invalida su startup cache: sin eso, un cambio de +chrome arranca con la interfaz vieja y *parece* que el overlay no agarró. + +La capa de configuración de la v0.1 son cuatro ficheros —autoconfig, `atuq.cfg`, `chrome/atuq.css`, `policies.json`— y el CSS se registra como `USER_SHEET` desde autoconfig porque `userChrome.css` vive en el perfil y exigiría que el usuario prenda una pref: atuq tiene que verse como atuq en el primer arranque. Falta construirlo: su dep `firefox` está en vuelo. @@ -312,7 +320,8 @@ siguiente. | 3.a | PGO: perfil bajo sway headless, **sellado como artefacto propio** y consumido por hash | la otra mitad de la ganancia | 3 | | 3.b | `wasi-sdk` + `wasi-compiler-rt` ⇒ RLBox encendido | cierra el hueco de seguridad del §3.bis | 2 | | 4 | **`atuq`: receta derivada + overlay de chrome** ✅ v0.1 escrita | el andamio de todo lo demás | 3 | -| 4.b | Branding (`application.ini`, nombre del binario) + re-empaque de `omni.ja` | el chrome de verdad | 4, y ver el artefacto real | +| 4.b | Branding + re-empaque de `omni.ja` ✅ v0.2 `b3:7eff4ba4` | el chrome de verdad | — | +| 4.c | **`MOZ_BUILD_DATE` determinista en `firefox`** — hoy el `BuildID` es la fecha del build ⇒ el artefacto **no reproduce bit a bit** | el invariante de reproducibilidad | otro build de 4 h + re-sellar atuq | | 5 | Host de native messaging (tawasuyu) | los verbos del §6 | 4 | | 6 | `sct` v1 (extensión + testigo) | el diferenciador que nadie tiene | 5 | | 7 | Descargas al CAS | 6.2, y alimenta 6.9 | 5 | diff --git a/recipes/firefox.toml b/recipes/firefox.toml index 4329d7fc..978f2f7c 100644 --- a/recipes/firefox.toml +++ b/recipes/firefox.toml @@ -133,6 +133,16 @@ flags = [] # Entra en `hash_inputs` A PROPÓSITO (cambia el contenido del artefacto), y usa `zig objcopy`, que # siempre está en el sandbox ⇒ no agrega una dep de build. strip_debug = true +# ⚠ DEUDA MEDIDA EL 2026-09-05: ESTE ARTEFACTO NO REPRODUCE BIT A BIT ═══════════════════════════ +# `application.ini` del artefacto sellado trae `BuildID=20260905035306`: la FECHA Y HORA del build. +# Dos construcciones de esta misma receta, con el mismo hash, producen bytes distintos — que es +# exactamente el agujero que el invariante de reproducibilidad existe para cerrar, y no se ve en +# `build-state.json` porque el ArtifactHash es input-addressed y no se mueve. +# El arreglo es el que ya usa Alpine: exportar `MOZ_BUILD_DATE` con un valor determinista en las +# fases (su APKBUILD lo deriva de `SOURCE_DATE_EPOCH`; acá el candidato natural es un valor fijo, +# que al vivir en el texto de la fase entra en `hash_inputs` y queda declarado). +# NO se aplica de paso: cambiar una fase re-hashea la receta y cuesta otro build de cuatro horas +# más el re-sellado de `atuq`, que cuelga de ella. Es su propia unidad de trabajo. [build.phases] configure = '''