Files
takana/docs/state/fuzz-verificado.tsv
T
Sergio db7fd81236 parches: los 8 FUZZ del catálogo, mirados uno por uno — y un libro que se auto-invalida
`vigia-parches.py --all` sobre las 99 aplicaciones de parche del catálogo: **0 FALLA**, y 14 líneas
FUZZ (8 pares parche/fuente distintos). FUZZ significa que `patch` metió el cambio ADIVINANDO dónde
porque el contexto no casaba, y si cayó en el sitio correcto sólo lo dice el diff. Nadie los había
mirado. Los miré todos:

  · **libxml2 / CVE-2026-6732** — el que más importaba, un parche de seguridad con fuzz 2 en sus dos
    hunks. Cayó bien: los dos dentro de `xmlParseReference()`, las 4 llamadas pasan `ctxt->userData`
    y no sobrevive ningún `sax->characters(ctxt,` en el fichero. El fuzz era por un offset de 226
    líneas, no por el sitio.
  · **doas / rowhammer** — el otro sensible, toca la decisión de privilegio. Cae dentro de
    `checkconfig()` y queda `rv=permit(...); if(rv==0)→permit`, coherente con el `if(rv!=0)→EPERM`
    de `main()`. Y el fuzz lo causa un parche ANTERIOR de la propia cadena (el `#ifdef DOAS_CONFDIR`
    que inserta `configuration-directory.patch`), no un cambio de upstream — que es una causa que no
    se me habría ocurrido sin abrirlo.
  · **wayland**, **mesa** (×3), **cairo** (×2), **firefox** (time64 y fix-rust-target): todos en su
    sitio, cada uno comprobado contra lo que el propio parche declara querer.
  · **gnupg / 0001-include-unistd** — hallazgo: el parche está OBSOLETO. Añade `#include <unistd.h>`
    y upstream YA lo trae dos líneas más abajo, así que sólo lo duplica. Inocuo (el header tiene
    guardas) y por eso el fuzz 2: cambió el contexto porque upstream lo incorporó. Quitarlo re-hashea
    gnupg, así que se paga cuando se re-selle por otro motivo.

Y para que esto no se repregunte en cada corrida —lo que vuelve ruido al vigía, y así es como se
pierde el FALLA del día que aparezca— los veredictos van a `docs/state/fuzz-verificado.tsv` con un
cuarto estado, FUZZ✓.

La clave del libro NO es (receta, parche) sino (receta, parche, HUELLA), donde la huella resume el
texto del parche MÁS el pin de la fuente. Tocá el parche o subí la versión y la huella cambia, la
entrada deja de casar y el vigía vuelve a preguntar. Es lo contrario de una lista de excepciones: no
hay forma de silenciar algo y que siga silenciado cuando cambió. Y el vigía imprime la línea lista
para pegar debajo de cada FUZZ sin verificar, porque calcular la huella a mano es justo la fricción
que hace que nadie lo anote.

Los dos FUZZ de waterfox quedan FUERA del libro a propósito: no los verifiqué en esta ronda y
waterfox está fuera de alcance. Van a seguir saliendo como FUZZ, que es lo honesto — el libro dice
lo que se miró, no lo que se supone.
2026-09-05 17:34:28 +00:00

3.5 KiB

1# fuzz-verificado.tsv — los FUZZ de `scripts/vigia-parches.py` que YA se miraron, con su veredicto.
2#
3# Un FUZZ no se puede resolver automáticamente: `patch` metió el cambio ADIVINANDO dónde, y si cayó
4# en el sitio correcto sólo lo dice el diff. Pero una vez mirado, el veredicto no caduca solo:
5# depende del TEXTO del parche y de la FUENTE, y las dos están pineadas.
6#
7# Por eso la clave no es (receta, parche) sino (receta, parche, HUELLA), donde la huella resume el
8# parche + el pin de la fuente. Tocá el parche o subí la versión y la huella cambia, la entrada deja
9# de casar y el vigía VUELVE A PREGUNTAR. No es una lista de excepciones: no hay forma de silenciar
10# algo y que siga silenciado cuando cambió.
11#
12# La línea lista para pegar la imprime el propio vigía debajo de cada FUZZ sin verificar.
13#
14# receta<TAB>parche<TAB>huella<TAB>veredicto (qué se comprobó, no «ok»)
15#
16# ⚠ Los dos FUZZ de waterfox NO están acá a propósito: no los verifiqué en esta ronda y waterfox está
17# fuera de alcance. Van a seguir saliendo como FUZZ, que es lo honesto.
18cairocairo-ctime-r.patch053bd7e1c4b4051f2026-09-05: los 3 hunks exactos — conf.set('HAVE_CTIME_R',1) queda DESPUÉS del bucle check_funcs; el `if false` envuelve subdir('cairo-trace') y NO subdir('cairo-script'); el tercero va tras meson.override_dependency ⇒ la .pc sobrevive sin los exe csi-*
19cairo-sharedcairo-ctime-r.patch053bd7e1c4b4051f2026-09-05: misma huella que `cairo` (mismo parche, misma fuente pineada) ⇒ mismo veredicto
20doasrowhammer.patch22d6f35cf2e6fa572026-09-05: el hunk cae dentro de checkconfig() y queda rv=permit(...); if(rv==0)→permit, coherente con main() que hace if(rv!=0)→EPERM. El fuzz lo causa un parche ANTERIOR de la cadena (el #ifdef DOAS_CONFDIR de configuration-directory.patch), no un cambio de upstream
21firefoxtime64.patch66bc1630adc67e1b2026-09-05: now_including_suspend() y now_awake() quedan con libc::timespec::default(); no sobrevive ningún literal `tv_sec: 0` en zeitstempel/src/unix.rs
22firefoxfix-rust-target.patchcd6f96abf42122e42026-09-05: la asignación cae justo tras el `return None` de find_candidate y el return usa ensure_unicode; no queda ninguna LLAMADA a find_candidate(candidates), sólo su def
23gnupg0001-include-unistd.patchd688ed86408ec74d2026-09-05: entra en el bloque de includes de scd/app.c — pero upstream YA trae <unistd.h> dos líneas más abajo ⇒ el parche está OBSOLETO y sólo lo duplica (inocuo: el header tiene guardas). Quitarlo re-hashea gnupg, así que se paga cuando se re-selle por otro motivo
24libxml2CVE-2026-6732.patchd67f9694dcad492f2026-09-05: los 2 hunks dentro de xmlParseReference(); las 4 llamadas pasan ctxt->userData y NO queda ninguna sax->characters(ctxt, ni sax->cdataBlock(ctxt, en todo el fichero. El fuzz es por el offset de 226 líneas, no por el sitio
25libxml2-sharedCVE-2026-6732.patchd67f9694dcad492f2026-09-05: misma huella que `libxml2` ⇒ mismo veredicto
26mesamesa-version-script-comma.patch6054348f4a56ac2c2026-09-05: version-script y dynamic-list quedan en forma COMA ('-Wl,--version-script,'+ruta), que es exactamente lo que el parche declara querer
27mesa-llvmpipemesa-version-script-comma.patch6054348f4a56ac2c2026-09-05: misma huella que `mesa` ⇒ mismo veredicto
28mesa-swrastmesa-version-script-comma.patch6054348f4a56ac2c2026-09-05: misma huella que `mesa` ⇒ mismo veredicto
29waylandwayland-scanner-dup2-output.patchb56341a45c5e7b1d2026-09-05: el dup2(outfd, STDOUT_FILENO) cae dentro de main() de src/scanner.c y no queda NINGÚN freopen en el fichero