takana

2,410 Commits 1 Branch 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
sergioandClaude Opus 4.8	d99ed58850	harkaq: revertir busybox (era runtime base, rompía builds) + coordinar el §3 con Fable 5 DOS ERRORES MÍOS, uno de dirección y otro técnico, los dos en la cosecha automática: 1. DIRECCIÓN: declaró `busybox` como dep en 29 recetas — cuando la Etapa C lo está ELIMINANDO (USERLAND_COMPONENTS=[uutils,findutils,…], ya cerrada; joyas-reusables §5 lo confirma: "uutils… Ubuntu 25.10 los envía como default"). Estaba cimentando la deuda que el roadmap borra. 2. TÉCNICO: busybox YA está en el runtime base de harkaq (`ro /bin/busybox`, `ro /bin/sh` — el sandbox corre `sh -c` y /bin/sh→/bin/busybox). Es CONTRATO, no dep. Declararlo apila el busybox de hammer sobre el de Alpine y ROMPE el build: binutils daba "cannot run C compiled programs" en las DOS máquinas. Verificado: sin busybox declarado, binutils construye (b3:f4507dcd…). Y la cadena se explica: binutils roto ⇒ zlib (que lo declara) tampoco construía. Auditoría de la cosecha (diff real, no la línea completa del +): añadió sólo 5 deps distintas — make ×73, busybox ×29, perl ×8, pkgconf ×5, binutils ×1. Sólo busybox estaba mal; las otras 4 son deps reales medidas. busybox revertido de 30 recetas (queda sólo en busybox.toml, pre-existente). Es el mismo error que ya me habían señalado con otro disfraz: MEDIR BIEN Y ACCIONAR MAL. harkaq midió correcto (el build toca /bin/busybox: es el shell); la acción correcta no era declararlo sino reconocerlo como contrato. + COORDINACIÓN del §3 con Fable 5 (mismo diseño, tareas repartidas): - Su lección casper queda CONFIRMADA y REFORZADA: la clausura de build no sólo le FALTAN las clases del mundo (offline) — también le SOBRA casi todo (headers, gcc). Medido: htop (estático, 0 NEEDED) no toca NADA al correr ⇒ política = su binario. - Su "la clase viaja como campo de la ConcesionCapacidad, sin formato nuevo" se cumple LITERALMENTE: lo firmado es format::Permisos = u32 bitmask en 36 bytes canónicos (Ring 0) ⇒ las clases SON los bits. La cripto no se toca. - Diseño unificado: frontera (clases, u32, declaradas) + detalle (paths, Landlock, medidos). D3 rige en ambos. - Reparto: clases→Fable 5; medición/harness→Opus. CONTACTO: runtime-policy.sh ahora emite la CLASE detectada (/etc/resolv.conf→dns, /etc/ssl/certs→tls-certs, …), no sólo el path: la medición alimenta la tabla, la tabla decide el bit. - Consumidor esperando: plan-jaula-juegos F1 (Steam que no puede leer ~/.ssh). + juez.sh (§10): nombre único por corrida (con uno fijo pega en caché ⇒ falso "sin evidencia"). Fue el juez quien destapó todo esto en su primera corrida real. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-16 23:14:19 -04:00
sergioandClaude Opus 4.8	be52e735ab	cierres §3: política de runtime derivada por medición (sin tocar la cripto) El #3 decía "la clausura medida por harkaq en build = permisos del binario instalado". MEDIDO: es falso en dos ejes, y por eso NO se implementó así. 1. SUJETO: la clausura de BUILD (zlib.h, make, gcc) no es la de RUNTIME. Un build lee headers; el binario resultante no. Dos clausuras, dos sujetos. 2. GRANULARIDAD/CRIPTO: lo que la ConcesionCapacidad firma NO es card-core:: Permissions (struct) sino format::Permisos = u32 bitmask, dentro de `mensaje_capacidad` = hash(32)\|\|permisos_le(4) = 36 bytes canónicos, zero-alloc, con espejo no_std en wawa-kernel (Ring 0). Meterle paths rompería TODAS las firmas y contradice el "capacidad = frontera física, no tabla" que el propio plan cita como referencia. ⇒ Camino elegido: la concesión firmada QUEDA INTACTA (frontera gruesa, Ring 0) y la clausura granular se deriva por MEDICIÓN como política Landlock en userspace, donde Vec<String> sí cabe. Coexisten: el kernel verifica la frontera, Landlock aplica el detalle. runtime-policy.sh: corre el binario bajo la jaula con política mínima DERIVADA (harkaq-base-closure, no a mano) y resta el BASELINE del lanzador (el sh deniega locale/ld.so.cache; sin restarlo, la política del binario se lleva esa basura). Demo real — htop (musl-estático): baseline 3 paths del sh; htop --version no tocó NADA propio ⇒ su política de runtime es sólo `ro <su binario>`. Medido, no supuesto. htop tiene 0 NEEDED: para un estático la política NO sale de las libs, sólo de correrlo — lo que confirma que la técnica de harkaq es la única vía para el #3. + FIX del lector (lo cazó el chequeo anti-pérdida `nº ACCESS == denials`): descartaba los ACCESS previos al canario porque hasta verlo no sabe su domain= — pero el sh deniega ANTES del probe y esas son suyas. El kernel contaba 4 y el lector recibía 1. Ahora se bufferizan con su domain y se rescatan retroactivamente al ver el canario. Sin ese chequeo habría emitido una política con 1 de 4 accesos, perfectamente creíble. (Primer intento de fix —drenar el socket al ver el deallocated— era plausible y NO era la causa: el contador siguió en 4 vs 1.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-16 22:02:05 -04:00

Author

SHA1

Message

Date

sergioandClaude Opus 4.8

d99ed58850

harkaq: revertir busybox (era runtime base, rompía builds) + coordinar el §3 con Fable 5

DOS ERRORES MÍOS, uno de dirección y otro técnico, los dos en la cosecha automática:

1. DIRECCIÓN: declaró `busybox` como dep en 29 recetas — cuando la Etapa C lo está
   ELIMINANDO (USERLAND_COMPONENTS=[uutils,findutils,…], ya cerrada; joyas-reusables
   §5 lo confirma: "uutils… Ubuntu 25.10 los envía como default"). Estaba cimentando
   la deuda que el roadmap borra.
2. TÉCNICO: busybox YA está en el runtime base de harkaq (`ro /bin/busybox`, `ro
   /bin/sh` — el sandbox corre `sh -c` y /bin/sh→/bin/busybox). Es CONTRATO, no dep.
   Declararlo apila el busybox de hammer sobre el de Alpine y ROMPE el build:
   binutils daba "cannot run C compiled programs" en las DOS máquinas. Verificado:
   sin busybox declarado, binutils construye (b3:f4507dcd…). Y la cadena se explica:
   binutils roto ⇒ zlib (que lo declara) tampoco construía.

Auditoría de la cosecha (diff real, no la línea completa del +): añadió sólo 5 deps
distintas — make ×73, busybox ×29, perl ×8, pkgconf ×5, binutils ×1. Sólo busybox
estaba mal; las otras 4 son deps reales medidas. busybox revertido de 30 recetas
(queda sólo en busybox.toml, pre-existente).

Es el mismo error que ya me habían señalado con otro disfraz: MEDIR BIEN Y ACCIONAR
MAL. harkaq midió correcto (el build toca /bin/busybox: es el shell); la acción
correcta no era declararlo sino reconocerlo como contrato.

+ COORDINACIÓN del §3 con Fable 5 (mismo diseño, tareas repartidas):
  - Su lección casper queda CONFIRMADA y REFORZADA: la clausura de build no sólo le
    FALTAN las clases del mundo (offline) — también le SOBRA casi todo (headers, gcc).
    Medido: htop (estático, 0 NEEDED) no toca NADA al correr ⇒ política = su binario.
  - Su "la clase viaja como campo de la ConcesionCapacidad, sin formato nuevo" se
    cumple LITERALMENTE: lo firmado es format::Permisos = u32 bitmask en 36 bytes
    canónicos (Ring 0) ⇒ las clases SON los bits. La cripto no se toca.
  - Diseño unificado: frontera (clases, u32, declaradas) + detalle (paths, Landlock,
    medidos). D3 rige en ambos.
  - Reparto: clases→Fable 5; medición/harness→Opus. CONTACTO: runtime-policy.sh ahora
    emite la CLASE detectada (/etc/resolv.conf→dns, /etc/ssl/certs→tls-certs, …), no
    sólo el path: la medición alimenta la tabla, la tabla decide el bit.
  - Consumidor esperando: plan-jaula-juegos F1 (Steam que no puede leer ~/.ssh).

+ juez.sh (§10): nombre único por corrida (con uno fijo pega en caché ⇒ falso
  "sin evidencia"). Fue el juez quien destapó todo esto en su primera corrida real.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-16 23:14:19 -04:00

sergioandClaude Opus 4.8

be52e735ab

cierres §3: política de runtime derivada por medición (sin tocar la cripto)

El #3 decía "la clausura medida por harkaq en build = permisos del binario
instalado". MEDIDO: es falso en dos ejes, y por eso NO se implementó así.

1. SUJETO: la clausura de BUILD (zlib.h, make, gcc) no es la de RUNTIME. Un build
   lee headers; el binario resultante no. Dos clausuras, dos sujetos.
2. GRANULARIDAD/CRIPTO: lo que la ConcesionCapacidad firma NO es card-core::
   Permissions (struct) sino format::Permisos = u32 bitmask, dentro de
   `mensaje_capacidad` = hash(32)||permisos_le(4) = 36 bytes canónicos, zero-alloc,
   con espejo no_std en wawa-kernel (Ring 0). Meterle paths rompería TODAS las
   firmas y contradice el "capacidad = frontera física, no tabla" que el propio
   plan cita como referencia.

⇒ Camino elegido: la concesión firmada QUEDA INTACTA (frontera gruesa, Ring 0) y
la clausura granular se deriva por MEDICIÓN como política Landlock en userspace,
donde Vec<String> sí cabe. Coexisten: el kernel verifica la frontera, Landlock
aplica el detalle.

runtime-policy.sh: corre el binario bajo la jaula con política mínima DERIVADA
(harkaq-base-closure, no a mano) y resta el BASELINE del lanzador (el sh deniega
locale/ld.so.cache; sin restarlo, la política del binario se lleva esa basura).

Demo real — htop (musl-estático): baseline 3 paths del sh; htop --version no tocó
NADA propio ⇒ su política de runtime es sólo `ro <su binario>`. Medido, no supuesto.
htop tiene 0 NEEDED: para un estático la política NO sale de las libs, sólo de
correrlo — lo que confirma que la técnica de harkaq es la única vía para el #3.

+ FIX del lector (lo cazó el chequeo anti-pérdida `nº ACCESS == denials`): descartaba
los ACCESS previos al canario porque hasta verlo no sabe su domain= — pero el sh
deniega ANTES del probe y esas son suyas. El kernel contaba 4 y el lector recibía 1.
Ahora se bufferizan con su domain y se rescatan retroactivamente al ver el canario.
Sin ese chequeo habría emitido una política con 1 de 4 accesos, perfectamente creíble.
(Primer intento de fix —drenar el socket al ver el deallocated— era plausible y NO
era la causa: el contador siguió en 4 vs 1.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-16 22:02:05 -04:00