a1ab8774c55325aaafa0332b9db2b4bb7b489c7c
726
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  sergioandClaude Opus 4.8
|
a1ab8774c5 |
harkaq: mtdev — deuda de config.sub CERRADA con patch soberano (+ límite del modelo descubierto)
El único caso de deuda de soberanía del barrido: mtdev copiaba el config.sub/guess del autoconf de ALPINE (/usr/share/autoconf/build-aux/) porque el suyo (1.1.6) no conoce *-musl. harkaq lo cazó como lectura no declarada del rootfs. CERRADO con recipes/mtdev-config-sub-musl.patch: 11 líneas, +`-musl*` a la whitelist de OS del config.sub DEL PROPIO TARBALL. Ahora es input soberano (hasheado con la receta), sin leer Alpine. Se quitó el `cp /usr/share/autoconf/...` del configure. Verificado: mtdev construye (b3:47708e40) sin tocar /usr/share/autoconf. Método (con un tropiezo honesto): casi afirmo que el `cp` era espurio porque el config.sub en work/sources/mtdev daba exit 0 con musl — pero ese source estaba MUTADO por un build previo (el cp lo había reemplazado por el de Alpine). El tarball ORIGINAL fresco NO conoce musl (exit 1). Casi valido sobre un source contaminado; me salvó chequear el exit code, no el output. DESCUBIERTO AL CERRARLO: mtdev tenía DOS deudas de Alpine, no una. También usa `compiler = "gcc"` (gcc de Alpine, no zig). Bajo la jaula la política deniega /usr/bin/gcc (sonda esperada) y el configure da "C compiler cannot create executables". Es parte de matar-gcc (kernel, cmake, mtdev), frente aparte. LÍMITE DEL MODELO (nuevo, documentado en needs-review): harkaq clasifica gcc como "sonda esperada" SIEMPRE, así que marca la fase Hermetico — pero para una receta compiler=gcc, gcc es ESENCIAL y el build no compila sin él. harkaq no distingue "gcc sondeado (ignorable)" de "gcc = el compilador". Caso límite real del clasificador; no invalida el cierre de config.sub (producción no usa la jaula). make declarado en mtdev (deuda declarable restante). config.sub fuera de needs-review; queda anotado el gcc-compilador. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
35f58aa75b |
harkaq: granja con volumen + auto-shutdown VALIDADA end-to-end
Test real (worker + volumen + helper), no en el papel. Las 3 piezas:
1. worker midió lz4+bzip2 → volumen
2. tras 1 ciclo idle SE AUTO-ELIMINÓ (verificado: el server desapareció solo)
3. volumen SOBREVIVIÓ con los 2 verdicts; helper efímero ccx13 los recogió al
hub y se auto-destruyó
3 bugs cazados EN EL TEST (no adivinados):
- falta --exclude /work: work/=69GB colgó el rsync del up horas
- cpx11 'unsupported' en hel1 (AMD sin stock) → ccx13
- collect llamaba harvest con 'local' (rsync a un worker inexistente): ahora
sólo recoge; clasificar es paso aparte (worker mide, hub clasifica)
+ auto-delete por API REST (curl+metadata), NO hcloud CLI (la golden no lo trae).
El ID propio sale del metadata service, no del nombre.
Cierra los 2 huecos de la 1ª campaña: idle cobrando (ahora auto-delete) y
dependencia de que yo esté viva (ahora el volumen persiste). Runbook:
docs/runbooks/harkaq-granja-volumen.md. Volumen clausurado tras el test (€0).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
f7916b5ee9 |
harkaq: granja con volumen persistente + workers auto-terminantes
La arquitectura que la 1ª campaña pidió a gritos (el worker quedó idle ~4h
cobrando). Tres piezas en harkaq-vol.sh {up|collect|close|status}:
1. VOLUMEN persistente (harkaq-cosecha): los workers escriben verdicts a
/mnt/cosecha, que sobrevive a su destrucción ⇒ NO dependo de estar viva para
no perder el trabajo.
2. AUTO-SHUTDOWN (harkaq-campana-vol.sh): tras IDLE_CICLOS ciclos con 0
mediciones nuevas, el worker SE AUTO-ELIMINA. En Hetzner un server apagado
sigue cobrando ⇒ apagar de verdad es delete. Vía API REST + curl + metadata
service (NO hcloud CLI: la golden Ubuntu no lo trae; curl siempre está). El
ID propio sale del metadata, no del nombre.
3. collect: monta el volumen en un helper barato efímero (o un worker vivo),
rsync al hub, corre el harvest, destruye el helper. close: detach+delete del
volumen (deja de cobrar, ~€0.44/mes mientras exista).
+ dos fixes de la 1ª campaña horneados en el bucle: borra el artefacto -hkm tras
medir (envenenaba la caché) y los dos gates (ABI>=7 + binario-con-jaula).
El token va al worker (para auto-delete): riesgo acotado — worker efímero, sin
servicios entrantes salvo SSH-por-clave, destruido al terminar.
Bug cazado antes de gastar: las llaves {..} dentro del mensaje de ${1:?...}
cerraban la expansión (CMD salía 'status}').
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
7d760f274e |
harkaq: declarar deps medidas por el kernel (cosecha automática)
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de Landlock en un build real: el kernel vio al build usarla sin declararla, y el store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5). Recetas:bash binutils busybox bzip2 No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
fecdeab8f1 |
harkaq: declarar deps medidas por el kernel (cosecha automática)
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de Landlock en un build real: el kernel vio al build usarla sin declararla, y el store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5). Recetas:dhcpcd strace No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
895e8202fa |
harkaq: revisadas las 5 irreducibles — 2 recuperadas, 3 casos genuinos diagnosticados
Ninguna de las 5 necesitaba una receta nueva. Eran falsos irreducibles por
política incompleta + un caso real de de-Alpinización.
FALTABAN 2 SONDAS EN LA POLÍTICA: /usr/bin/cpp (frontend del preprocesador de
gcc, mismo grupo que gcc/c89/c99) y /usr/bin/getent (utilidad NSS de musl).
hammer NO las construye ⇒ se deniegan y clasifican (D3), como gcc. Sin ellas en
`# expect`, arrastraban la receta entera a irreducible. Añadidas a base.policy y
a harkaq-farm-setup.sh (para los próximos workers). Re-clasifiqué SIN re-medir
(la clasificación lee la política; los veredictos crudos no cambian).
nm/ranlib NO se añadieron como sondas: los provee binutils ⇒ son DECLARABLES.
Ponerlos como esperadas dejaría a una receta usar el ranlib de Alpine en vez de
decir "declará binutils" — lo contrario de lo que se busca.
RECUPERADAS (declaradas y fuera de needs-review):
dhcpcd → make, pkgconf strace → make
QUEDAN 3, cada una una historia distinta (README en needs-review):
ncurses fs.make_dir /usr/lib — ESCRITURA en install, no lectura de Alpine
(DESTDIR de la receta), NO de-Alpinización.
mtdev config.guess/sub del autoconf de Alpine — LA ÚNICA deuda de soberanía
genuina del barrido (parchar mtdev o escribir recipes/autoconf.toml).
perl /etc/hosts,/etc/resolv.conf — config de sistema para tests de red; el
build completa igual. Runtime base o denegación benigna, no Alpine.
Resultado del barrido completo: de 83 recetas, la deuda de soberanía REAL es UN
caso (mtdev/autoconf). Todo lo demás era declarable o sondas.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
7206626e25 |
harkaq: el disparo de cosecha es loop nohup, NO cron (arje-zero es PID1)
El laptop corre arje-zero como init (no systemd, systemctl no existe) y no tiene crond activo. El crontab que instalé anoche corrió 0 veces: validé que la LÍNEA corría a mano, nunca que un daemon fuera a dispararla. Mismo patrón que me mordió toda la sesión — validar la pieza, no el sistema. Disparo real: scripts/farm/harvest-loop.sh con setsid nohup. Sobrevive el fin de sesión, no un reboot (eso pediría un servicio /etc/init.d, con root). + 2 bugs del harvest arreglados: flock anti-solape (dos ciclos editando+commiteando a la vez = árbol corrupto) y el rescate rechazaba recetas legítimas por la línea en blanco que add-deps añade (el + vacío no matcheaba [deps].build). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
7ec2e86b7b |
harkaq: declarar deps medidas por el kernel (cosecha automática)
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de Landlock en un build real: el kernel vio al build usarla sin declararla, y el store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5). Recetas:coreutils elfutils expat file flex gawk No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
8f94b8a251 |
harkaq: declarar deps medidas por el kernel (cosecha automática)
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de Landlock en un build real: el kernel vio al build usarla sin declararla, y el store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5). Recetas:sassc scdoc sed shadow socat sqlite tar tmux tree tzdata util-linux vim wget when which wpa_supplicant xorriso xz zlib No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
21ac060c4b |
harkaq: declarar deps medidas por el kernel (cosecha automática)
Cosecha desatendida de la campaña harkaq. Cada dep de acá la denunció el audit de Landlock en un build real: el kernel vio al build usarla sin declararla, y el store del hub confirma qué artefacto la provee (deuda DECLARABLE, §4.5). Recetas:gettext-tiny giflib git gnupg gperf gzip htop iproute2 jq kbd libassuan libcap libevent libffi libgcrypt libgpg-error libksba libnl libpng libsass libsodium libssh2 libudev-zero libusb libwebp libxml2 libyaml linux-generic linux-headers linux-metal linux-pam linux lz4 mandoc mtools musl nano npth openssh openssl parted pciutils pcre2 pigz procps-ng python3 readline rsync samurai ca-certificates curl doas dosfstools e2fsprogs fontconfig freetype No se tocó ninguna receta con deuda IRREDUCIBLE: declarar algo que el store no provee rompería el build en vez de arreglarlo. Esas van a tandas/needs-review-harkaq. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
593a11c034 |
harkaq: gate 2 de la campaña — ¿el binario TIENE la jaula dentro?
La golden hornea un target/release/hammer viejo y el rsync excluye /target ⇒ si el cargo build del provisioning no corre, el worker construye alegremente SIN JAULA y produce cero veredictos. PASÓ: la primera corrida molió 2 recetas con un binario del 29/06 (0 ocurrencias de 'harkaq' en strings) y las marcó 'sin veredicto' como si fuera culpa de las recetas. Ocho horas así son la noche entera perdida, y el log habría dicho 'salteada' — nunca 'estoy ciego'. Es el falso Hermetico de D9 mudado al orquestador: la ausencia como respuesta tranquilizadora. Ahora aborta si strings no encuentra harkaq en el binario. Mismo criterio que el gate del ABI: no medir es mejor que creer que se mide. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
32e8ac557d |
harkaq: runbook de la campaña desatendida (worker + cron, para retomar sin mí)
Estado escrito en el repo y no en mi cabeza: la campaña tiene que sobrevivir a que yo desaparezca al final del turno. Qué corre, dónde, cómo revisarlo por la mañana, cómo pararlo, y los rastrillos que ya se pagaron (el cd del cron, el pull sucio, cargo fuera del PATH). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
052f4f765e |
harkaq: Cargo.lock — libc en hammer-build (SIGTERM para el lector)
Sin esto el `git pull --rebase` del cron de cosecha falla con 'unstaged changes' y la cosecha nunca sincroniza con el otro agente: idle silencioso de noche, que es justo lo que la campaña existe para no tener. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
f783f0107d |
harkaq: campaña desatendida — medir→declarar→verificar, sin regex y sin preguntas
El problema real no es el coste de la tanda: es que una pregunta a las 3am son 8
horas de idle. Estas 3 piezas están hechas para que la noche no se desperdicie.
harkaq-campana.sh (worker) bucle autónomo: construye cada receta bajo la
jaula y guarda los veredictos crudos. Idempotente, saltea
lo medido, duerme y re-escanea. NUNCA bloquea esperando: un
build que falla no detiene la cola (y su veredicto interesa
igual — es cuando más importa saber qué tocó fuera). Gatea
por ABI>=7: moler la noche para producir "no sabemos" es
peor que no moler.
harvest-harkaq.sh (hub, cron) hermano de harvest-go.sh: baja veredictos,
clasifica contra el store COMPLETO, aplica las deps
DECLARABLES y commitea con `git add` explícito. La deuda
IRREDUCIBLE NO se toca (declarar algo que el store no
provee rompe el build en vez de arreglarlo) → needs-review.
harkaq-add-deps.py editor de recetas conservador: idempotente, preserva las
deps existentes, y ANTE LA DUDA NO TOCA (valida que el
resultado siga parseando como TOML y no encoja). Corre de
noche sobre la fuente de verdad del catálogo: un fichero mal
editado a las 3am no da un error, da una receta corrupta que
nadie mira hasta el lunes.
POR QUÉ NO HAY REGEX EN EL CAMINO CRÍTICO: intenté sacar la lista de "a quién le
falta declarar make" con uno y falló dos veces en la misma tarde. `\bmake\b`
colaba `cargo-make` (el guión ES límite de palabra). La versión estrecha perdía
LAS CINCO recetas donde harkaq había medido la deuda de verdad (`compile = "make
…"`: el carácter previo es una comilla). El número bailó 69→45→99 según el
retoque. Construí una herramienta de medición y después intenté adivinar con un
regex — la lista buena la da el kernel. El regex queda sólo para ORDENAR la cola.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
1e0bc98ad4 |
matar gcc: rollout de cmake HECHO en la granja — y los consumidores no hacían falta
cmake reconstruido en un worker efímero (regla: la cadena GUI no se rebuildea en
el laptop, el zig-skew rompe cairo) y cosechado al hub:
b3:834132e7…-cmake NEEDED = sólo libc.musl-x86_64.so.1
El viejo (99864dcc…, con libstdc++.so.6 + libgcc_s.so.1) queda en el store por si
algo lo referencia.
LOS 10 CONSUMIDORES NO SE RECONSTRUYERON, Y NO HACE FALTA. El fix quita la
dependencia de RUNTIME del artefacto DE CMAKE. Los consumidores sólo lo usaron
como HERRAMIENTA DE BUILD — sus artefactos no linkean libstdc++. Rebuildearlos
sólo daría frescura de hash, y eso pasa solo en su próximo build. Confundir "usó
la herramienta" con "linkea la librería" habría costado un rebuild de gtk4 para
nada. (Yo mismo había propuesto los 11; el radio real es 1.)
REGALO DEL ROLLOUT: el worker (Ubuntu 24.04, ccx23) y el laptop (CachyOS)
produjeron cmake con el MISMO HASH, bit a bit — el invariante central de hammer
confirmándose entre dos máquinas distintas sin que nadie lo buscara. Y como los
bytes son idénticos, el NEEDED del worker queda verificado por transitividad: no
hizo falta readelf allá (que además no está instalado en la golden).
Limpieza: removido store/834132e7…-cmake-nogcc (mi artefacto experimental).
harkaq-suggest INDEXA el store, así que un artefacto huérfano aparecería como
"proveedor" de paths y ensuciaría los diagnósticos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
ee51e5d596 |
harkaq: el kernel de hammer ya trae Landlock — ABI 7 verificado BOOTEANDO (Fase 1 precond. 1)
recipes/linux.toml: -e SECURITY -e SECURITY_LANDLOCK -e AUDIT. Era lo único que
faltaba para que harkaq corra DENTRO de hammer (VM/metal) y no sólo en el laptop
y la granja. El CONFIG_LSM del defconfig ya lista `landlock` de primero ⇒ bastó
encenderlo, sin tocar la cadena de LSMs.
AUDIT se fija explícito aunque ya viniera =y por defconfig: sin él el kernel no
emite un solo registro y harkaq certificaría TODO como hermético en silencio
(§3.4). Es la precondición de la que cuelga la evidencia; no se deja al azar de
un default.
VERIFICADO BOOTEANDO, no leyendo el .config — que dice lo que se compiló, no lo
que el kernel hace al arrancar. Misma disciplina de §3.1 (el ABI se consulta por
syscall, jamás por versión) llevada a la verificación: el único que sabe si
Landlock está vivo es el kernel vivo. scripts/harkaq/vm-abi-probe.c es un /init
de initramfs mínimo que pregunta y apaga:
===== HARKAQ EN EL KERNEL DE HAMMER =====
LANDLOCK ABI = 7
audit de denegaciones (>=7): SI
=========================================
Kernel nuevo: b3:f2583d61… (el hash cambia, como se esperaba; el viejo
34755ff2… decía "# CONFIG_SECURITY_LANDLOCK is not set").
Con esto las 4 precondiciones de la Fase 1 están cerradas y harkaq corre en las
tres máquinas del proyecto: laptop (ABI 10), granja (ABI 7 tras el bump de la
golden) y el kernel propio de hammer (ABI 7).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
caa23f9ab7 |
harkaq: seccomp implementado (D4) — denylist, no allowlist; el hash no se mueve
D4 declaraba seccomp "obligatorio, no opcional" y harkaq-exec tenía CERO
seccomp: el documento afirmaba algo que el código no hacía. Cerrado.
CORRECCIÓN DELIBERADA A D4: pedía ALLOWLIST por syscall, se implementó DENYLIST.
Un allowlist para builds ARBITRARIOS (compiladores, make, shells, linkers, perl)
es un blanco móvil que cada herramienta nueva rompe — el riesgo del §7 ("los
falsos positivos matan proyectos de sandboxing") aplicado a las syscalls, y con
peor final: un build que muere por una syscall legítima no da un diagnóstico
útil, da un misterio. Lo PELIGROSO sí es enumerable y estable: no hay build
honesto que cargue módulos, haga kexec o attachee un ptrace.
Denegadas: io_uring_*, ptrace, process_vm_{readv,writev}, bpf, userfaultfd,
keyctl/add_key/request_key, {init,finit,delete}_module, kexec_*,
perf_event_open, mount/umount2, open_tree/move_mount/fs*, setns.
pivot_root NO: bwrap lo usa ANTES de llegar a harkaq-exec.
EPERM y no KILL: matar deja un cadáver sin explicación; EPERM deja al build
fallar donde corresponde y al log decir por qué. Se instala DESPUÉS de
no_new_privs y de Landlock, justo antes del exec, y se hereda por fork/exec como
el dominio (D5). Si el kernel lo rechaza NO se corre el build (D7: media jaula
creyéndose entera es peor que ninguna).
Chequeo de arquitectura antes del número de syscall: los nros son POR ARCH y sin
el check un binario i386 podría colar otra syscall con el mismo número — el error
clásico de los filtros seccomp a mano.
COMPROBADO: ptrace → EPERM bajo la jaula (control positivo), y un build REAL de
zlib sale Hermetico ×3 con el hash del artefacto IDÉNTICO al de antes de seccomp
(b3:adc5c251…). Añadir media jaula no movió un byte — como debe ser: esto recorta
superficie de escape, no cambia el build.
El --seccomp <fd> de bwrap quedó SIN USAR: harkaq-exec ya corre dentro y con
no_new_privs puesto, así que instala el filtro él mismo — una pieza menos de
plumbing y el filtro queda al lado de la política que lo justifica.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
8f7109f4e9 |
harkaq: el barrido queda en 0 IRREDUCIBLES — perl ya existía (§4.11)
La única deuda irreducible del barrido (§4.10) era /usr/bin/perl en
ca-certificates y curl. Dos hallazgos al abrirla:
1. EL COMENTARIO DE ca-certificates.toml YA LO DECÍA, escrito por quien la portó:
"El resto del build (mk-ca-bundle.pl → cert.pem → split-ca-bundle.sh) usa el
perl + coreutils del rootfs". La deuda estaba escrita EN PROSA y era invisible
para el sistema; harkaq la convirtió en un veredicto. Es la tesis del §0 en una
línea: no hace falta que nadie DESCUBRA nada, hace falta que la máquina pueda
VER lo que ya se sabía.
2. LA RECETA TAMBIÉN EXISTÍA: recipes/incoming-kde/perl.toml, importada el 13/07
para la campaña KDE (syntax-highlighting e intltool exigen perl). CUARTA
convergencia independiente: dos campañas necesitaban el mismo binario y
llegaron por caminos que no se hablan.
Construye tal cual (b3:c7a899bd…) y con el artefacto en el store:
/usr/bin/perl → declarar dep: perl exit=0 ⇒ CERO deuda irreducible
EL BARRIDO DE 24 RECETAS QUEDA EN 0 IRREDUCIBLES. La métrica del §7 (<5%) se
cumple midiendo lo que la métrica quería medir: cosas que no sabemos construir.
Resultado: ninguna.
Receta promovida a recipes/perl.toml (no había canónica ⇒ sin colisión). Lo que
queda es mecánico y no es diseño: declarar `make` en las ~10 recetas que lo usan
y `perl` en ca-certificates/curl. OJO: eso re-hashea sus artefactos y son
paquetes del base-system (índice firmado 748) ⇒ decisión de rollout, no un sed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
13233ee4e9 |
harkaq: primer barrido en la granja — la deuda irreducible de la muestra es perl (§4.10)
harkaq-farm-setup.sh: provisiona un worker para barrer (idempotente; gatea por
ABI>=7 y aborta si no llega — con la golden vieja el barrido daría SinEvidencia
en TODO). Deriva el runtime base DEL ROOTFS DEL WORKER, no copia el del laptop:
es por-rootfs (§4.3) y los sonames dependen de la versión de Alpine.
Barrido: 24 recetas, 14 con veredicto. Primer número crudo: 4 irreducibles (29%).
ERA FALSO, y por dos motivos propios:
1. GAP DE POLÍTICA. Los `list` salían sólo de los ancestros de la clausura ⇒ una
receta SIN deps (bash) no generaba ni uno y todo escaneo del árbol caía como
denegación (/usr/lib). Listar NO es leer: Landlock separa READ_DIR de
READ_FILE ⇒ la estructura del árbol es CONTRATO. Se puede `ls /usr/lib` sin
leer un solo fichero no declarado; la deuda es leer lo ajeno, no saber que
existe. Idem /var/tmp: con --tmp-overlay / es scratch descartable, como /tmp.
2. La heurística del catálogo es por NOMBRE y un fichero no se llama como su
paquete: /usr/bin/ranlib lo trae `binutils`, /usr/bin/diff lo trae
`diffutils`. El único que sabe la verdad es el STORE (conoce la lista de
ficheros de cada artefacto) — y el worker tiene 103 artefactos contra los
cientos del hub.
⇒ EL WORKER MIDE, EL HUB CLASIFICA. Misma separación que lector/clasificador: el
que tiene el privilegio —o los datos— hace lo mínimo. Reclasificado en el hub:
bash ranlib,/usr/lib,/var/tmp → nada (gap de política)
doas /usr/bin/diff → nada (diffutils lo provee)
ca-certificates /usr/bin/perl → /usr/bin/perl
curl /usr/bin/perl → /usr/bin/perl
RESULTADO: la deuda irreducible de toda la muestra es UN path — /usr/bin/perl
(2 de 14 = 14%). No hay recipes/perl.toml ni artefacto: deuda genuina y nombrada.
Todo lo demás era declarable (make ×10, ranlib→binutils, diff→diffutils).
Sigue por encima del <5% del §7, pero el perfil es el que importa: NO hay cola
larga de sorpresas. La deuda de un catálogo entero se resume en "declarar make" y
"no tenemos perl".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Fable 5
|
ea28a3dbcc |
docs: SDD 17 — cierres de frontera priorizados × cruce con crates de tawasuyu
Los 10 cierres que caen solos de los 3 invariantes (bit-repro, CAS, clausura-como-política), cada uno cruzado con el crate/arquitectura reusable de tawasuyu que lo abarata. Top-2: consenso de reconstrucción (fork-proof+umbral) y hammer why-differs (format+reconcile). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
cba59e829b |
harkaq: la granja VPS ya puede ser el compilador continuo — golden bumpeada a 6.17 (ABI 7)
El VPS va a ser el compilador permanente ⇒ harkaq TIENE que correr ahí o el
frente queda como decoración de laptop. Verificado de punta a punta en un worker
efímero desde la golden, no en el papel:
antes: kernel 6.8.0-134 → Landlock ABI 4 → sin audit → SinEvidencia siempre
después: kernel 6.17.0-40 → Landlock ABI 7 → AUDIT ✓
`apt install linux-image-generic-hwe-24.04` (archivo estándar de Ubuntu 24.04, sin
PPA ni cambiar distro), reboot, y la cadena COMPLETA de evidencia corre igual que
en el laptop:
same-exec 2 registros · new-exec 0 (el ciego) · new-exec-logon 4
domain=14e9f83c2 blockers=fs.read_file path="/etc/passwd" dev="sda1" ino=133259
El store del catálogo (103 artefactos) sobrevivió el bump intacto.
NUEVA GOLDEN: snapshot 408909310 "hammer-golden-harkaq-6.17-2026-07-15".
farm-up.sh pasa a usarla por defecto. La vieja (405120842) queda como fallback.
+ harkaq-uapi.h — EL HALLAZGO QUE IMPORTA para un compilador continuo: **el kernel
y los headers envejecen por separado**. El worker corre 6.17 pero su
linux-libc-dev es 6.8 y NO define NADA de lo necesario: ni los flags de log de ABI
7/8, ni AUDIT_LANDLOCK_ACCESS/DOMAIN (¡los tipos de registro!), ni IOCTL_DEV de
ABI 5. El kernel puede; el compilador no sabe pedírselo.
Es el mismo error de §3.1 al revés: allá, deducir el ABI de la versión del kernel;
acá, de la versión de los headers. NINGUNA de las dos dice la verdad — la única
fuente es el syscall en runtime. Estas constantes son números de contrato de UAPI,
estables por definición, seguros de fijar con #ifndef.
Sin esto harkaq sólo compila en distros con headers al día, que es justo lo que un
compilador continuo NO puede exigir. Y el modo de falla habría sido el peor: sin
AUDIT_LANDLOCK_ACCESS el lector filtraría por un número que no conoce y vería CERO
denegaciones — el falso `Hermetico` de D9, esta vez por headers viejos.
Nota: ABI 7 da el audit (lo que el proyecto necesita); TSYNC (ABI 8) pide 7.0 y no
está — es robustez opcional de D5, no un bloqueo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
b122ded31f |
matar gcc: cmake deja de arrastrar el runtime C++ de Alpine (§4.9) + /proc es contrato
harkaq (§4.6) dejó UN solo caso irreducible en el primer barrido: brotli pidiendo
libstdc++.so.6.0.34 + libgcc_s.so.1. Pero brotli es C, no C++ — la libstdc++ no
era suya: era de `cmake`, su dep de build.
store/99864dcc…-cmake/usr/bin/cmake
NEEDED: libstdc++.so.6, libgcc_s.so.1, libc.so
"gcc retenido para {kernel, cmake}" no era una concesión de BUILD-TIME como
sonaba: el artefacto de cmake arrastraba el runtime C++ de Alpine hacia dentro de
CADA build que lo declarara como dep. Un agujero de soberanía viajando por el
grafo de deps, invisible en la receta del consumidor. harkaq lo señaló desde el
consumidor, que es donde se ve.
EL ARREGLO NO TOCA EL COMPILADOR — gcc sigue compilando cmake (camino
conocido-bueno; zig c++ segfaultea el cmake mínimo). Sólo deja de enlazar su
runtime en dinámico:
CXX='g++ -static-libstdc++ -static-libgcc' LDFLAGS='-static-libstdc++ -static-libgcc'
Medido:
antes NEEDED: libstdc++.so.6, libgcc_s.so.1, libc.so
después NEEDED: libc.musl-x86_64.so.1 (y corre: cmake version 3.31.6)
EL PAGO: brotli —el único irreducible del barrido— pasa a Hermetico ×3 fases,
artefacto sellado b3:bc900676…. El barrido queda 0 irreducibles de 6. El caso que
iba a contar contra el <5% no era una receta mal escrita: era una herramienta de
hammer filtrando Alpine.
+ /proc como superficie de CONTRATO (lo destapó el configure de brotli, que lee
/proc/cpuinfo y /proc/meminfo): bwrap monta un /proc FRESCO dentro del pidns, no
sale del rootfs Alpine y no ve al host ⇒ contrato, no deuda. Mismo caso que
/cache. El hash del artefacto es idéntico antes y después de añadirlo: cambia el
veredicto, no el build.
COSTO DEL ROLLOUT: cambiar recipes/cmake.toml re-hashea cmake y sus 3
consumidores (brotli, libjpeg-turbo, libtiff = 6 sellados). Radio chico, PERO
libjpeg-turbo y libtiff son la cadena GUI y la regla es no rebuildearla en el
laptop (zig-skew rompe cairo) ⇒ el rebuild va al worker.
LO QUE NO CIERRA: /usr/bin/gcc, c89, c99, ldd y el plugin LTO (§4.7) siguen
siendo SONDAS — la jaula las deniega, los builds completan igual, y denegarlas es
lo correcto. El gcc de Alpine sigue en el rootfs y sigue haciendo falta para
{kernel, cmake} en BUILD-TIME. Lo cerrado es la filtración a RUNTIME, que es la
que contaminaba artefactos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
993060630d |
harkaq: el bucle CERRADO — de Impuro a Hermetico sobre una receta real (§4.7)
Diagnosticar no vale nada si no se puede accionar. El bucle completo sobre recipes/zlib.toml, cada paso guiado SÓLO por lo que dijo harkaq: zlib tal cual → Impuro: /usr/bin/make → "declarar dep: make" + make → Impuro: /usr/bin/ranlib → "declarar dep: binutils" + binutils → Impuro: liblto_plugin.so → irreducible ⇒ clasificar final → Hermetico ×3 fases, artefacto b3:adc5c251… SELLADO Cada capa que se pela destapa la siguiente, y TODAS convergen en el gcc de Alpine. El último hallazgo es el que no se encuentra a mano: los binutils DE HAMMER —ya declarados como dep— cargan el plugin LTO del gcc DE ALPINE (/usr/libexec/gcc/x86_64-alpine-linux-musl/15.2.0/liblto_plugin.so). No es un fallo de declaración de la receta: es un agujero de soberanía DENTRO de un artefacto que hammer construye. Va a denegación esperada por la misma razón que /usr/bin/gcc (§4.2): el build completa sin él ⇒ es una SONDA, no una necesidad, y bloquearla es DESEABLE — impide que los binutils de hammer usen el plugin de Alpine por detrás. D3 otra vez: no se calla, se clasifica. Detalle que confirma el modelo: el hash del artefacto es IDÉNTICO antes y después de clasificar la sonda (b3:adc5c251… las dos veces). Clasificar cambia el VEREDICTO, no el BUILD. Es el principio de H1 sosteniéndose solo: la evidencia es comportamiento, no identidad (recipe.rs:228, y por eso Evidence está fuera de hash_inputs). Y eso es lo que `Hermetico` significa ahora, con todo el peso: el kernel certificó que ese build no usó NADA fuera de su clausura declarada, y el canario prueba que el certificado no es el silencio de un lector roto. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
d0c9cdfa33 |
harkaq: deuda declarable vs irreducible (§4.5) + primer barrido de Fase 2 (§4.6)
La métrica del §7 (<5% de recetas necesitan excepción) medía otra cosa. zlib
salió Impuro por /usr/bin/make y parecía runtime base: NO lo es. recipes/make.toml
existe, store/fbad44ac…-make está sellado y SWAP_MAKE es uno de los swaps del
selfhost-verify ⇒ a zlib le falta una LÍNEA en [deps], no una excepción.
declarable el store ya provee el path ⇒ arreglo mecánico → NO cuenta
irreducible nadie lo provee ⇒ receta nueva o runtime base → SÍ cuenta
harkaq-suggest.py cruza cada path de deuda contra el store (el mapeo de §4.1 al
revés: el path relativo dentro del artefacto ES el path del sandbox):
/usr/bin/make → declarar dep: make
/usr/lib/libz.so.1.3.2 → irreducible (la zlib de hammer da libz.a estático,
no .so ⇒ NO se arregla declarando)
El diagnóstico deja de ser "algo pasó" y pasa a ser "hacé esto".
PRIMER BARRIDO (6 recetas C, fuentes cacheadas):
Hermetico ............... 0
sólo deuda DECLARABLE ... 5 ← y la deuda es EL MISMO path en las 5: /usr/bin/make
con deuda IRREDUCIBLE ... 1 (brotli)
Lo que importa: la deuda de 5/6 es UN SOLO path y se arregla con una línea. No
hay cola larga de excepciones — que era el riesgo de muerte del §7.
Y el caso irreducible es la frontera CONOCIDA: brotli (C++) pide
/usr/lib/libstdc++.so.6.0.34 y /usr/lib/libgcc_s.so.1 — el runtime C++ del gcc de
Alpine, que hammer no construye. Es exactamente lo que la campaña "matar gcc" ya
tenía identificado. TERCERA vez que harkaq llega por su cuenta a una lista que
otro frente ya tenía: los swaps del selfhost-verify (§4.3), los binutils (§4.4)
y ahora el runtime C++.
Honestidad: 6 recetas no son 750 y son las fáciles. 1/6 = 17%, muy por encima del
<5% — pero el único caso es un problema conocido, nombrado y compartido con otros
dos frentes, no una cola de sorpresas. El barrido grande es trabajo de granja.
Bug del barrido encontrado por el propio barrido: copiar la receta a otro
directorio rompe la resolución de deps.build (son relativas al dir de la receta)
⇒ brotli fallaba con "no pude cargar la dep 'cmake'" y se descartaba EN SILENCIO
— o sea que se descartaban justo las recetas CON deps, las interesantes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
47982d7c6a |
harkaq: HITO DE FASE 1 — wiring en Rust; veredicto por fase sobre una receta real
crates/hammer-build/src/harkaq.rs + Sandbox::bwrap_args_harkaq: harkaq sale de `hammer build`, no de un script. Deriva la política de la clausura declarada (D1), lanza el lector, mete harkaq-exec como último eslabón antes del `sh -c`, y recoge el Verdict por FASE (configure/compile/install son bwraps distintos ⇒ dominios distintos ⇒ un veredicto cada uno). EL HITO, sobre recipes/zlib.toml (receta real del catálogo): configure → Hermetico esperadas (14): /usr/bin/gcc deuda: ninguna ✓ compile → Impuro DEUDA (1): /usr/bin/make → rc=126, la jaula lo frenó El diagnóstico completo de zlib cabe en una frase: lo único que toma de Alpine sin declararlo es `make`. INERTE sin HARKAQ=1: mismos args de bwrap, mismo entorno, ningún proceso extra. Requisito duro, no cortesía — 700+ artefactos sellados no pueden cambiar de hash por encender un diagnóstico. Los 57 tests previos del crate siguen verdes sin tocar, que es la prueba. harkaq-policy es PURO y se testea sin kernel (4 tests nuevos, como pide §4): traduce store→sandbox, excluye la metadata `.hammer/` del artefacto, y deja listables los ancestros de cada fichero de la clausura. La integración se delató sola en su PRIMERA corrida real: faltaba /cache como superficie de contrato (ZIG_GLOBAL_CACHE_DIR=/cache/zig — zig CREA dirs ahí) y la fase moría con `fs.make_dir /cache/zig/tmp`. De ahí que las superficies de contrato las decida el Sandbox (que sabe qué montó) y no harkaq: /cache sólo existe si hay cache_dir, y una política que nombre un path inexistente aborta el build a propósito. libc en hammer-build: Child::kill() manda SIGKILL y el lector moriría MUDO, sin emitir el Verdict — justo lo que no queremos de un componente cuyo producto ES el veredicto. Hace falta SIGTERM. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
ed614e6898 |
harkaq: el runtime base DERIVADO (§4.3) + el diagnóstico sobre un configure real (§4.4)
harkaq-base-closure.py: deriva el cierre dinámico del runtime base. Es D1
aplicado a la base — mantenerla a mano sería el "alguien mantiene un perfil de
permisos" que D1 dice que mata a todos los sandboxes. No usa ldd (resolvería
contra el HOST, no contra el rootfs Alpine): lee los DT_NEEDED del ELF y
resuelve dentro del rootfs por las rutas de musl. Emite symlink Y destino: el
kernel denuncia el fichero real (libz.so.1.3.2) pero el build abre por el nombre
corto (libz.so.1).
VALIDACIÓN: el cierre derivado de {sh,busybox,bash,coreutils,env} reproduce
EXACTAMENTE las 7 librerías que las rondas 2-3 habían descubierto a mano, en una
sola pasada, y además caza los symlinks y libc.musl-x86_64.so.1 que se habían
escapado. El método es computable, no adivinado.
§4.4 — con el entorno del Sandbox real replicado (CC="zig cc -mcpu=baseline",
AR, SOURCE_DATE_EPOCH, LC_ALL=C), configure llega mucho más lejos: 205
denegaciones del kernel, y clasificadas:
esperadas (170): /usr/bin/gcc, /usr/bin/ldd ← sondas de compilador
DEUDA (34) en 8 paths:
/usr/bin/{ld,nm,objdump,strip} ← binutils de ALPINE
/usr/bin/{make,getconf}
/usr/lib/gcc/x86_64-alpine-linux-musl ← libdir del gcc de ALPINE
/opt ← bug de política
Es la tesis del §0 hecha dato: un configure que se creía hermético va a buscar
los binutils y el libdir de gcc de Alpine. Y la clasificación es lo que lo hace
legible — sin ella son 205 denegaciones planas y el hallazgo queda enterrado;
con ella son 8 paths accionables. Coincide con los swaps del selfhost-verify y
con la campaña "matar gcc" (recipes/binutils.toml existe justo porque zig provee
as/ld/ar pero el resto se toma de Alpine).
Bug de política encontrado por el propio experimento: /opt sale como deuda
porque la política concede `ro /opt/zig` pero no deja LISTAR el padre. Regla
general: todo directorio concedido necesita `list` en sus ancestros, o el escaneo
del padre es un falso positivo. harkaq-policy.sh ya lo hace para la clausura de
las deps; falta para las superficies de contrato.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
77317a7291 |
harkaq: Verdict clasificado (base|esperada|deuda) + el runtime base es por forma de build
harkaq-verdict.py: clasifica las denegaciones crudas. Va DELIBERADAMENTE fuera del lector — éste corre con CAP_AUDIT_READ y clasificar es POLÍTICA, no privilegio (mismo argumento que Q1c). De yapa: se itera sin recompilar el binario capabilitado y sin perder el setcap. Las expectativas viajan en la propia política como `# expect <path>` (una sola fuente de verdad; harkaq-exec las ignora como comentario). SinEvidencia manda sobre todo: si el lector no es confiable no se clasifica nada — reinterpretarlo sería el falso Hermetico que el canario existe para impedir. MODE=base rc=0 Hermetico esperadas: /usr/bin/gcc deuda: ninguna ✓ MODE=zlib rc=1 Impuro DEUDA: /usr/lib/libz.so.1.3.2 §4.3 — ¿aguantan los 5 paths en otra forma de build? Medido con un configure de autotools REAL (libgpg-error, MODE=configure): ronda 1: /bin/bash, /bin/coreutils ronda 2: libacl, libattr, libcrypto, libreadline, libutmps ronda 3: libncursesw, libskarnet ronda 4: /usr/bin/c89, /usr/bin/c99, /usr/bin/ldd, /usr/bin/make NO: el runtime base es POR FORMA DE BUILD (~16 entradas para autotools, no 5). Pero converge en 3 rondas (34 denegaciones → 5) y se queda chico ⇒ la métrica de <5% de la Fase 2 sigue siendo plausible. Hallazgo: **el runtime base no es una lista de binarios, es su CIERRE de .so** (bash arrastra libreadline+libncursesw; coreutils arrastra libacl+libattr). Es computable con ldd, no adivinable ⇒ harkaq-policy debe derivarlo igual que deriva la clausura de las deps. Misma idea, otro origen. Y el residuo es todo señal, nada ruido: c89/c99/ldd son sondas de compilador de Alpine (→ esperadas, como gcc) y /usr/bin/make es una decisión de diseño real — hoy los builds de hammer usan el make de Alpine sin declararlo. Es EXACTAMENTE lo que los swaps del selfhost-verify reemplazan uno a uno: la lista de deuda de harkaq y la lista de swaps del bootstrap son la MISMA lista, descubierta por dos caminos independientes. Que coincidan es la mejor validación externa del método. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
61171bfe7f |
harkaq: Q2 RESUELTA — el runtime base son 5 paths, y aparece una 3ª categoría
Método (lo importante): NO se adivina, se mide. MODE=base corre SIN ninguna dep
declarada ⇒ sin clausura que pueda explicarlas, toda denegación es runtime base
por definición. Aísla la respuesta sin juicio de valor.
MODE=base, hello.c mínimo con zig cc: 18 denegaciones, 4 paths distintos
(contador del kernel 19 = 18 + canario ✓):
8× /dev/urandom 6× /usr/lib/os-release 3× /dev/null 1× /usr/bin/env
Y el build salió rc=0: no son cosas que el build NECESITE, son cosas que INTENTA
— pero salen en todos los builds y sin tratarlas entierran la deuda real.
La partición cierra en TRES categorías, todas medidas (§4.2):
- Contrato del sandbox: /src /out /tmp /dev/null(rw) /dev/urandom /proc
/opt/zig — los monta BWRAP, no son Alpine ⇒ no son deuda. Ésta era la línea
divisoria que faltaba.
- Runtime base Alpine: /bin/sh /bin/busybox /lib/ld-musl /usr/bin/env
/usr/lib/os-release. CINCO. ⇒ el resto de Alpine es deuda genuina, y eso
hace viable todo el planteo.
- Denegación ESPERADA (no estaba en el diseño): /usr/bin/gcc. zig cc lo sondea
3× y el build sale rc=0 igual ⇒ NO es ruido a permitir, es la jaula haciendo
su trabajo: concederla dejaría a zig invocar el gcc de Alpine por detrás,
justo lo que la campaña "matar gcc" persigue a mano. Es D3 literal ("una
denegación esperada no se calla, se CLASIFICA") y confirma que no tener
`quiet` era correcto: silenciarla habría borrado el hallazgo.
El contraste con el mismo runtime base:
MODE=base rc=0 Impuro [ /usr/bin/gcc ] ← esperada
MODE=zlib rc=1 Impuro [ /usr/lib/libz.so.1.3.2 ] ← DEUDA PURA, sin ruido
Consecuencia de diseño para el Verdict: las denegaciones tienen que venir
CLASIFICADAS (base|esperada|deuda), no en lista plana. `Hermetico` debe
significar "cero deuda", no "cero denegaciones" — si no, ningún build real lo
alcanzaría jamás.
Gotchas medidos: /dev/null es destino de ESCRITURA (rw, no ro) y el piso duro es
/bin/sh→busybox→ld-musl (sin eso ni el canario corre ⇒ sólo SinEvidencia).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
24c6ab455e |
harkaq: §4 corregido (política POR FICHERO) + Q2 con método y primeros datos reales
CORRECCIÓN ESTRUCTURAL del §4 (otra herencia del marco nix). El Draft 2 decía
`fs_ro: [store paths de la clausura]`. Falso: esos paths NO existen dentro del
sandbox. `Sandbox::bwrap_args` apila las deps con --overlay-src y las FUNDE en
el mismo /usr que el rootfs Alpine, a propósito, para que el compilador las
encuentre sin plumbing de flags. Medido:
/usr/include/zlib.h (dep DECLARADA) dev=63 ino=13641973
/usr/include/stdio.h (Alpine, NO declarado) dev=63 ino=4196788
/usr/include (el directorio) dev=61 ino=15 ← overlayfs, uno
Una regla sobre /usr concede las dos ⇒ la evidencia no valdría nada. Ni `dev`
distingue. ⇒ La clausura se enumera FICHERO A FICHERO (computable: en el host
sabemos qué aporta cada dep). Dos consecuencias: `list` ≠ `ro` (pkgconf NECESITA
escanear /usr/lib/pkgconfig, pero listar no es leer; Landlock separa READ_DIR de
READ_FILE) y máscara por tipo (derechos de-sólo-dir sobre un fichero ⇒ EINVAL y
la regla entera se cae).
Piezas nuevas: harkaq-policy.sh (deriva la clausura, D1) + q2-runtime-base.sh
(responde Q2 midiendo, no adivinando) + harkaq-exec con `list`/máscara por tipo.
Q2, primeros datos con un build REAL en el sandbox REAL contra la dep zlib:
estado: Impuro | canario: True | contador kernel: 3
fs.read_file /usr/bin/env
fs.read_file /usr/lib/libz.so.1.3.2 ← la zlib de ALPINE!
El build se linkaba contra la zlib de Alpine en vez de la dep declarada (que
aporta libz.a). Sin harkaq eso pasa en verde y el artefacto queda dependiendo de
Alpine. ES EXACTAMENTE EL BUG DEL §0, cazado en un build real.
Piso duro del runtime base: /bin/sh → /bin/busybox → /lib/ld-musl (sin eso ni el
canario corre ⇒ el mínimo es "lo que hace falta para que el canario pueda correr").
Dos rastrillos: el canario no puede depender de un binario (`cat` moría en
/bin/cat ⇒ ahora `read _ < $CANARY`, sólo builtins) ni vivir en /tmp (la política
concede `rw /tmp` ⇒ el canario caía DENTRO de la clausura y no denegaba nada).
El segundo lo cazó D9 MISMO: el lector se negó a certificar en vez de decir
Hermetico. El canario funcionando como se diseñó, sobre un bug de quien lo diseñó.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
4eecba06f4 |
harkaq: Fase 1 — la cadena corre de punta a punta (Hermetico / Impuro sobre kernel real)
Tres piezas nuevas, las del §4 del SDD:
- harkaq-audit.c lector de evidencia; HOST junto a hammerd, CAP_AUDIT_READ;
espera el canario (que revela el domain=), junta las
denegaciones de ESE dominio, cruza contra el contador del
kernel al liberarse, y emite el Verdict JSON de 3 estados.
- harkaq-exec.c aplica la política y execea el builder; DENTRO de bwrap,
estático (rootfs musl). Negocia el ABI por syscall (D7:
<min rechaza, <7 avisa SIN EVIDENCIA) y pone
LOG_NEW_EXEC_ON + TSYNC.
- harkaq-run.sh encadena lector+bwrap+exec, pone el canario con nonce y
espera a que el lector confirme que escucha (--ready-fd)
antes de arrancar el build: sin esa barrera el canario se
emitiría sin nadie escuchando y daría SinEvidencia por una
carrera, no por un problema real.
El hito, con comandos sintéticos sobre el kernel real (ABI 10):
limpio {"estado":"Hermetico","canario_visto":true,"contador_kernel":1,"denials":[]}
impuro {"estado":"Impuro","canario_visto":true,"contador_kernel":2,
"denials":[{"blockers":"fs.read_file","path":"…/README.md",…}]}
Canario visto y contador coherente en ambos ⇒ los 3 estados de D9 funcionan.
Q1c contestada en la práctica: el privilegio vive en un helper chico con
`setcap cap_audit_read,cap_audit_control`, NO en hammerd entero.
Sutileza medida: lo que DAC ya bloquea es INVISIBLE para harkaq (el hook del
LSM no llega a correr). Descubierto porque el escenario "impuro" con
/root/.bashrc (drwx------) dio Hermetico: DAC lo bloqueó antes que Landlock.
No rompe D2 (si DAC lo bloqueó, el build tampoco lo usó ⇒ Hermetico es cierto)
pero acota el diagnóstico, y al escribir tests hay que elegir paths que DAC
permita o el control no controla nada.
Falta para cerrar Fase 1: harkaq-policy derivando de la clausura real + el
contraste receta-de-Alpinizada vs. receta-que-no. El rebuild del kernel
(SECURITY_LANDLOCK) NO bloquea el hito: sólo hace falta para que harkaq corra
DENTRO de hammer; el laptop ya está en ABI 10.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
6419f2a952 |
harkaq: Q1b CERRADA — la evidencia cruza el userns y el canario es la clave primaria
Banco: scripts/harkaq/q1b-attrib.c. Dos builds CONCURRENTES en bwrap --unshare-all (los ns de Sandbox::bwrap_args), sin privilegio (uid 1000), canarios con nonce distinto, lector en el host como root. (a) ✅ Los registros CRUZAN el userns/pidns/mountns (6 registros llegaron al lector del host) y cruzan con builds SIN privilegio, que es como corren de verdad. ⇒ harkaq-audit vive en el host junto a hammerd; la arquitectura del §4 se sostiene. (b) ✅ El canario con nonce ATRIBUYE: AAAA=1 BBBB=1, cero cruces con 2 builds en paralelo. ⇒ la granja puede construir en paralelo sin contaminarse la evidencia entre builds. Tres hallazgos colaterales que valen más que el veredicto: - El contador quedó VALIDADO: dos `deallocated denials=1`, uno por dominio, cuadrando con 1 ACCESS cada uno ⇒ el chequeo anti-pérdida (nº ACCESS == denials) está medido, no supuesto. - La identidad sobrevive a los ns: pid=8498 uid=1000 son del HOST (adentro del pidns la víctima es pid 1). - dev+ino identifican el OBJETO, no el BUILD: los 2 canarios dan el mismo ino=4457713 (ambos bindean /etc/hostname). Atribuir por dev/ino habría fundido dos builds leyendo el mismo fichero no declarado — el caso más común que harkaq va a ver. La clave es domain=, y el canario la revela. ⇒ D9 hace TRES trabajos con un mecanismo: honestidad (§3.4), clave primaria (§3.5) y, vía el contador, detección de pérdida. Nota de método: esta corrida también falló 2 veces más, y las 2 el banco afirmó algo falso con total confianza. (1) `cat $canario >/dev/null` — /dev no estaba en la clausura ⇒ sh fallaba en el REDIRECT y cat no corría; el rc=1 no era del canario. (2) Como root, bwrap no pudo ni ejecutar el binario y el veredicto imprimió "NADA cruzó ⇒ replantear la arquitectura" a partir de cero estímulo (causa: --unshare-all mapea sólo uid 0→0; CAP_DAC_OVERRIDE en userns sólo vale sobre uids MAPEADOS ⇒ root-en-userns no atraviesa un home drwx------). Fix: drop_privs() + gate de estímulo (exit 4 si una víctima no sale con status 0). Van 3 veces en una sesión que un cero fue el instrumento y no el kernel, con quien escribía el banco mirando de frente ese riesgo. harkaq sin canario no es un riesgo de configuración: es el comportamiento por defecto. Quedan Q1c (privilegio de harkaq-audit: mejor un helper acotado que hammerd entero) y Q1d (qué ruta reporta exe= con --bind /src). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
ad0948cfb0 |
harkaq: Q1 CERRADA — la evidencia llega; + D9 (canario deliberado) y el banco de pruebas
Q1 era el gate del proyecto (¿llegan los registros AUDIT_LANDLOCK_* a un lector?). Medido en el laptop (ABI 10) con scripts/harkaq/q1-audit.c: ✅ VIABLE. El multicast AUDIT_NLGRP_READLOG entrega blockers=fs.read_file path="/etc/passwd" dev="nvme1n1p6" ino=4458369 + exe=/comm= del que lo intentó. Es el diagnóstico de de-Alpinización que el SDD promete, saliendo del kernel sin instrumentar nada. Dos precondiciones que el Draft 2 no tenía, ambas medidas: - audit_enabled=1 NO viene de fábrica (sin audit=1 en cmdline, sin auditd) ⇒ cero registros de cualquier escenario. AUDIT_SET o audit=1 horneado. - LOG_NEW_EXEC_ON es OBLIGATORIO: same-exec=2 registros, new-exec=0, new-exec-logon=4. harkaq restringe y DESPUÉS execea el builder ⇒ sin el flag certificaría herméticos TODOS los builds, denials=[], sin un error. D9 (nueva, no negociable): el canario lo fabrica harkaq. Se investigó si el registro `deallocated denials=N` servía de verificación cruzada gratis: NO. Medido con ventana de 6s, un dominio con flags default y denegación post-exec no emite NADA (ni allocated, ni access, ni el contador); y el `allocated` es perezoso (llega pegado al primer denial logueado) ⇒ su ausencia tampoco prueba nada. Un build hermético y un lector ciego son bit-idénticos: denials=[]. El Verdict pasa a 3 estados (Hermetico / Impuro / SinEvidencia). El contador SÍ sirve para lo otro: nº ACCESS == denials caza registros perdidos por backlog (riesgo real con la granja en paralelo). Nota de método (§3.4): la 1ª corrida dio 0 en los 3 escenarios y "confirmaba" la hipótesis. Era el instrumento roto (AUDIT_GET con NLM_F_ACK: el ACK llegaba antes que la respuesta → enabled=-1 → nunca se encendía el audit). Se cazó sólo porque el CONTROL (same-exec) también dio 0, y eso era imposible. Es el modo de falla de harkaq en vivo sobre su propio banco. El test ahora aborta (exit 4) si no confirma audit_enabled=1. Nuevas Q1b (¿el lector ve a través del userns de bwrap? ¿cómo se atribuye un registro a SU build con la granja en paralelo?) y Q1c (privilegio de harkaq-audit). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
9478f4c065 |
docs: SDD 16 harkaq — Draft 2 reescrito contra la realidad del builder (bwrap, no nix)
El Draft 1 estaba escrito contra el sandbox de nix. hammer no construye con
nix: construye con bubblewrap (ADR 0004, hammer-build/src/sandbox.rs). Eso
invalidaba por irrelevancia el argumento anti-nix (§0), las FOD y su red
abierta (§6 + D8), Q5, y la Fase 3 del fetcher mediado — que el propio doc
marcaba como el mayor riesgo de cronograma, de "meses".
Fase 0 ejecutada (5 minutos, no días):
- ABI Landlock = 10 en el laptop (techo: audit/7, TSYNC/8, quiet/10).
- Kernel de hammer 6.16.12-metal: CONFIG_SECURITY_LANDLOCK ausente, pero
CONFIG_LSM ya lista landlock ⇒ falta un flag, no una versión. Q2 cerrada.
- Cero FODs: download.rs baja con curl en el HOST y --unshare-all incluye
--unshare-net ⇒ el fetcher mediado de D8 ya está construido. Fase 3 se
elimina.
La brecha real es otra y paga mejor: el sandbox monta un rootfs Alpine ENTERO
como capa base ⇒ política ⊋ clausura ⇒ una receta usa Alpine sin declararlo y
pasa en verde. Es el bug que la campaña de de-Alpinización caza a mano. D1 +
audit de ABI 7 lo vuelve mecánico (path/dev/ino de lo no declarado).
Encaje en el modelo de confianza (recipe.rs:229): H1 garantiza que lo
declarado PASA; harkaq que lo declarado BASTA. Complementos simétricos.
Sobreviven intactos D1 (política derivada), D2 (evidencia negativa) y D3
(cero quieting). Nuevo Q1 = el riesgo técnico real: cómo llegan los registros
AUDIT_LANDLOCK_* al lector (CAP_AUDIT_READ, auditd, userns, flags de exec).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
e263b66ec1 |
mirada/USB: telemetría persistente en el pendrive + bump a mirada de hoy (fix musl en tawasuyu)
TELEMETRÍA (el pedido): el rootfs de la imagen es un initramfs = RAM pura y los logs iban a /run (tmpfs) ⇒ al apagar la máquina ajena no sobrevivía NADA. Ahora la imagen lleva 2da partición FAT32 MIRADALOG (512M), montada por findfs+LABEL con -o sync (un cuelgue de GPU o corte de luz no se lleva los logs). Cada arranque vuelca run-NNNN/ con: resumen (modo/GPU/driver), hardware (PCI vía sysfs, módulos, DRM, input, firmware), pantallas (status/modes por conector), dmesg ANTES y DESPUÉS de mirada, seatd, y el log del compositor+greeter con RUST_LOG=wgpu_core=debug + EGL_LOG_LEVEL=debug + LIBGL_DEBUG=verbose (para ver por qué wgpu eligió el backend y si hay float16). Shell de rescate + . FAT32 a propósito: el pendrive se lee después desde cualquier SO. metal-usb-sdboot.sh gana DATA_MB/DATA_LABEL genéricos (partición de datos opcional en la GPT). GOTCHAs verificados antes de confiar: el kernel linux-generic SÍ trae VFAT_FS=y + NLS + USB_STORAGE=y (sin eso no montaba); el busybox de Alpine NO trae el applet 00:00.0 Host bridge: Intel Corporation Tiger Lake-UP3/H35 4 cores Host Bridge/DRAM Registers (rev 01) 00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) 00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01) 00:07.0 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #0 (rev 01) 00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module (rev 01) 00:0a.0 Signal processing controller: Intel Corporation Tigerlake Telemetry Aggregator Driver (rev 01) 00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01) 00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01) 00:12.0 Serial controller: Intel Corporation 500 Series Chipset Family On-Package Integrated Sensor Hub (rev 20) 00:14.0 USB controller: Intel Corporation 500 Series Chipset Family On-Package USB 3.2 Gen 2x1 (10 Gbs) xHCI Host Controller (rev 20) 00:14.2 RAM memory: Intel Corporation 500 Series Chipset Family On-Package Shared SRAM (rev 20) 00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20) 00:15.0 Serial bus controller: Intel Corporation 500 Series Chipset Family On-Package I2C Controller #0 (rev 20) 00:15.1 Serial bus controller: Intel Corporation 500 Series Chipset Family On-Package I2C Controller #1 (rev 20) 00:16.0 Communication controller: Intel Corporation 500 Series Chipset Family On-Package CSME HECI #1 (rev 20) 00:1c.0 PCI bridge: Intel Corporation 500 Series Chipset Family On-Package PCI Express Root Port #5 (rev 20) 00:1d.0 PCI bridge: Intel Corporation 500 Series Chipset Family On-Package PCI Express Root Port #9 (rev 20) 00:1f.0 ISA bridge: Intel Corporation 500 Series Chipset Family On-Package eSPI Controller (rev 20) 00:1f.3 Multimedia audio controller: Intel Corporation 500 Series Chipset Family On-Package High Definition Audio (HD Audio) (rev 20) 00:1f.4 SMBus: Intel Corporation 500 Series Chipset Family On-Package System Management Bus (SMBus) (rev 20) 00:1f.5 Serial bus controller: Intel Corporation 500 Series Chipset Family On-Package SPI (flash) Controller (rev 20) 39:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. NV2 NVMe SSD [SM2267XT] (DRAM-less) (rev 03) 3a:00.0 Non-Volatile memory controller: ADATA Technology Co., Ltd. IM2P33F3 NVMe SSD (DRAM-less) (rev 03) (sí findfs/blkid) ⇒ el dump de PCI lee /sys/bus/pci/devices/*/ directo; sintaxis del init validada con busybox ash (no bash). BUMP mirada: el pin era 9967b02c (18-jun) — 439 commits viejo. Ahora 9a17fefc, que incluye el fix de portabilidad a musl que hice en tawasuyu (ioctl: glibc usa c_ulong, musl c_int ⇒ las constantes DRM casteaban mal y mirada-compositor NO compilaba para musl). mirada-compositor ya selló (87ced528); greeter/ctl en curso. + scripts/kde/{metal-desktop-image,plasma-start-metal}.sh del hilo KDE (imagen de escritorio en metal). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
964a6931d2 |
kde/Plasma: spectacle SELLA — la CAPTURA DE PANTALLA (la app más cara de la campaña)
spectacle 6.7.2 (7a6db883) → /usr/bin/spectacle. Cierre VERIFICADO, los 6 componentes de la cadena:
libKPipeWireRecord.so.6 + libopencv_core.so.410 + libopencv_imgproc.so.410 + libtesseract.so.5.5 +
libKF6PrisonScanner.so.6 + libKQuickImageEditor.so.1.
Cadena nueva completada en esta tanda:
ffmpeg 7.1 faafef5e libavcodec/avutil/avformat/avfilter/swscale — kpipewire los exige los
4 REQUIRED. ffmpeg NO usa autotools: su configure toma --cc/--ar/
--ranlib, y hay que darle wrappers de UN SOLO TOKEN (--ar="zig ar" con
espacio se ejecutaría como binario único — mismo gotcha que el AR de
los crates 'cc'). **--disable-autodetect** = determinismo: sin él
configure escanea el sandbox y activa libs a discreción.
libva 2.22.0 121cd0de libva.so + libva-drm.so, REQUIRED por kpipewire. Sólo la capa de
despacho; los drivers reales son RUNTIME (dlopen). Sólo backend DRM.
kpipewire 6.7.2 745665f3 KPipeWire + KPipeWireRecord. Deps: pipewire + ffmpeg + libva + gbm/EGL
(mesa) + libepoxy.
kquickimageeditor 0a4f8156 **BUMP 0.5.0 → 0.6.2.1**: spectacle 6.7 incluye
<KQuickImageEditor/AnnotationDocument>, que NO existe en la serie 0.5
(no tiene src/annotations). La 0.6.x suma deps propias: KF6Config
REQUIRED + OpenCV 4.7 (stack blur, WITH_OPENCV=TRUE por defecto).
Por qué era cara: TODO en spectacle es REQUIRED y casi nada degradable. En particular **KPipeWire no se
puede esquivar**: find_package va sin REQUIRED y set_package_properties lo marca TYPE REQUIRED (eso sí se
degrada con sed), pero src/CMakeLists.txt:101 linkea K::KPipeWireRecord INCONDICIONALMENTE.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
8207207251 |
kde/Plasma: pipewire 1.2.7 — el SERVIDOR de audio real (+ destraba la cadena de spectacle)
pipewire (6d15a22c) → libpipewire-0.3.so.0 + libspa-* + daemon 'pipewire' + **'pipewire-pulse'** (habla el protocolo PulseAudio, así que los clientes libpulse ya sellados le hablan) + tools (pw-cli/pw-play/ pw-record/pw-mon/pw-dump/...). Cierra el lado SERVIDOR del audio: hasta ahora sólo teníamos el CLIENTE (libpulse con -Ddaemon=false). Dos frentes lo necesitaban: (1) audio real de Plasma 6; (2) spectacle → kpipewire → pipewire. Fuente del gitlab.freedesktop.org (como networkmanager/modemmanager). Recortado al core+SPA: sin bluez5 (arrastraría los códecs aptx/ldac/aac/opus), sin jack/v4l2/libcamera/gstreamer/ffmpeg/vulkan/roc/lv2/ avahi/x11/echo-cancel-webrtc/libusb/flatpak/snap; systemd/logind/selinux/rtkit off (no hay systemd). alsa+sndfile+libpulse+dbus+udev enabled (las 4 ya selladas). GOTCHA static-vs-shared (variante nueva del patrón): **sin ncurses a propósito**. Su única consumidora es la tool pw-top (monitor de terminal), guardada por 'if ncurses_dep.found()'. El ncurses del catálogo es static-only y su .pc arrastra '-static' al link ⇒ 'error: using shared libraries requires dynamic linking' al enlazar pw-top contra libpipewire-0.3.so. Quitando la dep, meson saltea pw-top y el resto construye. (Alternativa futura si se quiere pw-top: variante ncurses-shared.) Próximo: ffmpeg → kpipewire → spectacle. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
abd7337069 |
kde/Plasma: tesseract/leptonica/kquickimageeditor — cadena de spectacle (queda 1 blocker: KPipeWire)
Selladas:
leptonica 1.85.0 e80a5d36 procesamiento de imagen; dep dura de tesseract. Codecs recortados a
las variantes .so/PIC que ya tenemos (libjpeg-turbo-shared +
libpng-shared + zlib-shared); TIFF/WEBP/OPENJPEG/GIF off.
tesseract 5.5.0 08c05238 OCR. spectacle lo exige DURO: pkg_check_modules(TESSERACT REQUIRED)
en CMakeLists:111, sin option() para apagarlo. Sólo la lib (sin
training tools, que piden pango/cairo/icu).
kquickimageeditor 0.5.0 3d4bd904 editor de imagen QtQuick; spectacle lo marca TYPE REQUIRED.
spectacle.toml se commitea CON su blocker documentado en la cabecera (misma convención que usaba
networkmanager-qt): **KPipeWire**. find_package(KPipeWire) va sin REQUIRED y set_package_properties lo
marca TYPE REQUIRED (eso se degrada con sed), PERO src/CMakeLists.txt:101 linkea
INCONDICIONALMENTE ⇒ no hay forma de compilar sin él. Falta la cadena pipewire → (ffmpeg, para
KPipeWireRecord) → kpipewire.
El resto de su cadena YA quedó resuelto y sellado esta sesión: opencv + prison-scanner + zxing-cpp +
tesseract + leptonica + kquickimageeditor + xcb-util-cursor (sin este último: 'No suitable backend
platform was found ... XCB-CURSOR').
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
b68970675b |
kde/Plasma: zxing-cpp 2.3.0 + prison-scanner (KF6PrisonScanner) — cadena de spectacle
zxing-cpp 2.3.0 (c98afd82) → libZXing.so: decodificador/codificador de códigos de barras y QR. prison-scanner 6.27.0 (cbfd6dcc) → libKF6Prison.so.6 + **libKF6PrisonScanner.so.6**. Por qué la variante: el prison canónico de esta cola se selló con WITH_ZXING=OFF/WITH_MULTIMEDIA=OFF ⇒ no provee KF6::PrisonScanner, y spectacle corta el build en seco: if (NOT TARGET KF6::PrisonScanner) message(SEND_ERROR "Prison built without required PrisonScanner") prison-scanner activa WITH_ZXING=ON + WITH_MULTIMEDIA=ON (qtmultimedia ya sellado). Nombre distinto para NO re-hashear el prison que ya consumen plasma-workspace/plasma-nm — mismo patrón que kcoreaddons-QML / kwindowsystem-QML / qcoro-shared. GOTCHA zxing: hay que compilar **READERS *y* WRITERS**. Con ZXING_WRITERS=OFF el header ZXing/BitMatrix.h ni se instala, y prison NO sólo escanea — también GENERA códigos (zxingutil.cpp/pdf417barcode.cpp lo incluyen) ⇒ 'fatal error: ZXing/BitMatrix.h file not found'. spectacle sigue sin construir: además exige (sin flag para apagarlos) pkg_check_modules(TESSERACT REQUIRED tesseract) — OCR, arrastra leptonica — y kquickimageeditor TYPE REQUIRED. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
e07e316c98 |
kde/Plasma: opencv 4.10.0 (core+imgproc) — dep de spectacle
opencv (79526f4b) → libopencv_core.so.4.10 + libopencv_imgproc.so.4.10 + opencv4.pc. spectacle (la herramienta de captura de pantalla) lo exige: find_package(OpenCV 4.7 REQUIRED core imgproc), lo usa en src/QtCV.h. OpenCV es enorme (~95MB de fuente, decenas de módulos): se recorta con **BUILD_LIST=core,imgproc** (CMake ni configura el resto) + todo OFF (apps/tests/docs/python/java/protobuf/DNN/GUI/video/ffmpeg/IPP/TBB/CUDA/ OpenCL/codecs). Los codecs WITH_* van OFF porque viven en imgcodecs, que no construimos. **GOTCHA zig-wrapper DURABLE (2da vez que aparece, ahora documentado):** el wrapper clásico de esta cola arma la lista de args en $a SIN comillas ⇒ SPLITEA cualquier arg con espacios. OpenCV pasa -DOPENCV_ALLOCATOR_STATS_COUNTER_TYPE="long long" ⇒ zig recibe 'long' suelto y falla con 'error: long: unrecognized file extension'. Fix acá: wrapper PASS-THROUGH con "$@" (OpenCV no es ECM/KDE, no necesita el filtro de -Wl,--fatal-warnings). Es el mismo bug que ya había pegado en libkscreen (moc_predefs con -I"dir1 dir2"). spectacle NO construye todavía: además de OpenCV exige KF6::PrisonScanner, y el prison sellado se hizo con WITH_MULTIMEDIA=OFF (sin el componente Scanner, que pide ZXing + Qt Multimedia). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
e8ab362dd4 |
kde/Plasma: kinfocenter + kmenuedit (info del sistema y editor de menú)
kinfocenter 6.7.2 (9dee4f29): bin kinfocenter + KCMs de hardware (kcm_cpu/interrupts/kwinsupportinfo/
xserver/opencl/energyinfo/...). kmenuedit 6.7.2 (d13a64f4): editor del menú de aplicaciones. Ambos sin
recetas nuevas.
DEUDA REGISTRADA — qtbase sin Vulkan: el KCM about-distro ('Acerca de este sistema') incluye
<QVulkanInstance>/<QVulkanFunctions> tanto en sus helpers (opengl-helper/vulkan-helper) como en
GPUEntry.h. Esos headers SÓLO los genera Qt6Gui si qtbase se configuró con Vulkan, y el qtbase sellado
NO lo tiene (vulkan-headers/vulkan-loader están sellados, pero los usa kwin directo, no Qt). Se podó el
KCM entero: activar vulkan en qtbase cascadearía un rebuild de TODO el stack Qt/KF6/Plasma (horas), como
ya se vio con el fix de zlib-shared → kwin(1825 obj)+plasma-workspace(1962 obj). Pendiente para una
próxima cascada planificada de qtbase (junto con otras features que falten).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
52ca9de8b7 |
kde/Plasma: systemsettings 6.7.2 — el CENTRO DE CONFIGURACIÓN
systemsettings (4c304dd8) sella a la PRIMERA: bin /usr/bin/systemsettings, NEEDED libKF6KCMUtils.so.6 + libKF6KCMUtilsCore.so.6 + libPlasmaActivities.so.7. Cero recetas nuevas (todas las deps ya selladas) y sin pelear DocTools: systemsettings lo declara en OPTIONAL_COMPONENTS. Era el hueco más grande del escritorio: los KCMs se habían apagado para poder compilar plasma-desktop, y sin systemsettings no hay shell donde alojarlos. Ahora existe el contenedor + ya hay KCMs reales construidos por otras piezas de esta sesión: kcm_networkmanagement (plasma-nm), kcm_pulseaudio (plasma-pa), kcm_powerdevilprofilesconfig (powerdevil), kcm_kscreen (kscreen). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
3e0194609a |
kde/Plasma: plasma-pa SELLA — el APPLET DE VOLUMEN, frente de AUDIO cerrado
plasma-pa 6.7.2 (51d7a25b): applet QML org.kde.plasma.volume + kcm_pulseaudio + audioshortcutsservice.
Cierra el frente de audio: hasta ahora el lab sólo tenía libcanberra con backend NULL (sin reproducción).
Cadena completa nueva:
alsa-lib/speexdsp/libsndfile → pulseaudio (cliente) → pulseaudio-qt → plasma-pa
pulseaudio 17.0 (108cac6e) → libpulse.so.0 + libpulse-mainloop-glib.so.0 + libpulse-simple.so.0 (+ .pc).
- **-Ddaemon=false -Dclient=true**: se construye SÓLO la biblioteca cliente. Es lo correcto acá — el
servidor de audio previsto es PipeWire (habla el protocolo PulseAudio) pero los clientes igual
linkean el libpulse de PulseAudio. Evita todo el árbol de módulos del daemon (alsa/bluez/jack/
avahi/orc/fftw/webrtc-aec).
- -Dglib=enabled es OBLIGATORIO (sin él no hay libpulse-mainloop-glib, que plasma-pa exige);
lo habilita glib-shared.
- **GOTCHA lld durable**: PulseAudio comparte UN map-file (version script) entre libpulse,
libpulse-simple y libpulse-mainloop-glib ⇒ al enlazar cada una, el script asigna PULSE_0 a símbolos
que viven en las OTRAS: 'version script assignment of PULSE_0 to symbol pa_glib_mainloop_new failed:
symbol not defined'. GNU ld sólo avisa; ld.lld (el de zig) lo trata como ERROR desde lld 17. Fix:
-Dc_link_args=-Wl,--undefined-version.
pulseaudio-qt 1.8.1 (c6849b9e) → libKF6PulseAudioQt.so.5, selló a la primera. OJO: NO está en el path de
plasma/ sino en download.kde.org/stable/pulseaudio-qt/, y la versión viva es 1.8.x (1.6.0 del
find_package es sólo el mínimo).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
85cfb02d4d |
kde/Plasma: powerdevil + kscreen (energía y pantallas) + base de AUDIO (alsa-lib/speexdsp/libsndfile)
powerdevil 6.7.2 (299af51a): daemon de energía + acciones (suspendsession/dimdisplay/dpms/
brightnesscontrol) + KCMs. kscreen 6.7.2 (ef6218e6): kcm_kscreen + kscreen KDED + kscreen-console +
hdrcalibrator.
Base de audio REAL (el lab sólo tenía libcanberra con backend NULL, sin reproducción):
alsa-lib 1.2.14 c6896caf libasound.so.2 (--disable-python)
speexdsp 1.2.1 dc235b15 libspeexdsp.so.1 (resampler de PulseAudio)
libsndfile 1.2.2 c44d0142 libsndfile.so.1 (--disable-external-libs: sin FLAC/Opus, que no están
sellados; WAV/AIFF/AU basta para sonidos del sistema). Necesita python3.
Siguiente eslabón: pulseaudio → pulseaudio-qt → plasma-pa (applet de volumen).
3 lecciones de la depuración de powerdevil (dep-set de 69):
- ** FALTABA** y el síntoma era engañoso: 'Could NOT find KF6 (missing: KIO KCMUtils
XmlGui)'. La cadena real es KF6ConfigWidgets→find_dependency(KF6WidgetsAddons) ausente ⇒ ConfigWidgets
NOT_FOUND ⇒ cascadea a XmlGui/KIO/KCMUtils. Para diagnosticar hay que seguir los 'could not be found
because dependency X' hacia ARRIBA, no fiarse de los componentes que CMake lista.
- **PlasmaWaylandProtocols/WaylandProtocols/qtwayland** son deps directas de todo lo que toca Wayland
(powerdevil, kscreen). Idem los QML modules (kscreen: org.kde.kitemmodels + org.kde.plasma.plasma5support
→ kitemmodels/plasma5support directos; ambos YA traen su qml/, no hacía falta variante QML=ON).
- **timeout del build**: mató powerdevil a mitad del rebuild de plasma-workspace (mi
cambio de zlib-shared cascadeó kwin[1825 obj]+plasma-workspace[1962 obj]). Usar timeouts largos
(9000) para recetas con dep-sets grandes. Además: 24778 AUTO-MATCHEA el propio
comando de chequeo → usar .
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
f5a3432831 |
kde/Plasma: plasma-nm 6.7.2 SELLA — el APPLET DE RED, frente de red cerrado
plasma-nm (6080f27f) construido: applet QML org.kde.plasma.networkmanagement + kcm_networkmanagement +
plugins VPN (openvpn/openswan/ssh/sstp/strongswan/iodine/fortisslvpn). Cierre verificado:
libKF6NetworkManagerQt.so.6 + libKF6ModemManagerQt.so.6 + libqt6keychain.so.1.
Cierra el frente que plasma-workspace esquivó parcheando NetworkManagerQt a opcional. Cadena entera:
glib-shared → networkmanager (libnm) → networkmanager-qt ─┐
glib-shared → modemmanager (libmm-glib) → modemmanager-qt ───┴→ plasma-nm
Deps nuevas de esta tanda:
modemmanager 1.22.0 9e4ce41d libmm-glib. -Dqmi/mbim/qrtr=false evita libqmi/libmbim/libqrtr;
polkit=no, udev=false (+udevdir explícito, lo exige el assert).
modemmanager-qt 6.27 37e954bb KF6ModemManagerQt (REQUIRED en el find_package(KF6) de plasma-nm
aunque no haya módem).
qtkeychain 0.16.0 6a1319b0 claves WiFi. **LIBSECRET_SUPPORT=OFF**: por defecto ON y exige
libsecret-1 (llavero de GNOME); apagado queda KEYCHAIN_DBUS =
kwallet vía Qt6DBus, que es el backend que KDE usa ⇒ cero deps nuevas.
OJO: el tag de git es '0.16.0' SIN prefijo 'v'.
libxslt 1.1.43 b41cb0fc xsltproc. A diferencia de NM (donde sólo servía a man/ y se degradó),
ModemManager lo USA de verdad: include/meson.build:25 genera
ModemManager-names.h desde header-generator.xsl.
qcoro-shared 0.12.0 b8ed5b49 el qcoro canónico sella sólo .a sin PIC (su CMake no fija
BUILD_SHARED_LIBS) ⇒ 'R_X86_64_32S QCoro::detail::TaskBase<QDBusMessage>
recompile with -fPIC' al linkear plasma-nm. Variante con
BUILD_SHARED_LIBS=ON; nombre distinto para no re-hashear el qcoro que
ya consumen plasma-workspace/powerdevil.
BUILD_OPENCONNECT=OFF es importante: con ON, plasma-nm hace find_package(Qt6WebEngineWidgets REQUIRED)
⇒ arrastraría qtwebengine (Chromium), diferido por el ADR.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 4.8
|
89569a6ce2 |
kde/Plasma: NetworkManager 1.52 + libndp → networkmanager-qt SELLA (blocker duro resuelto)
Habilitado por glib-shared (deuda Capa 0 recién saldada). La receta networkmanager-qt documentaba un '⛔ BLOCKER DURO': pkg_search_module(NetworkManager REQUIRED IMPORTED_TARGET libnm>=1.4.0) sin receta de NetworkManager en el catálogo. Resuelto: networkmanager 1.52.0 (f3d89133) → libnm.so.0 + libnm.pc + headers (NetworkManager.h/nm-version.h). - Fuente: gitlab.freedesktop.org (download.gnome.org sólo llega a NM 1.9.x; el proyecto migró). - **-Dcrypto=null es la clave**: NM ofrece crypto ∈ {nss,gnutls,null}; 'null' evita nss (→nspr/sqlite) y gnutls (→nettle/libtasn1/p11-kit), dos cadenas enormes. Sin validación de certificados 802.1X, pero libnm compila y la API D-Bus queda completa. - Deps duras satisfechas: libudev (libudev-zero ya sellado), gio (glib-shared), libndp (receta nueva), uuid (util-linux), dbus. - NM va pidiendo sus flags de a uno; los que hicieron falta: -Dld_gc=false (lld no soporta linker garbage collection), -Dsystemdsystemunitdir=no, -Dconcheck=false (curl), -Dnmcli=false/-Dreadline=none. sed a meson.build:92: find_program('xsltproc') es INCONDICIONAL pero xsltproc sólo se usa en man/ (no se construye con docs=false) → required:false, evita la receta libxslt entera. libndp 1.9 (036eb8c7): sin tarball con configure pregenerado (mirrors 404) ⇒ git-archive + con el autoconf/automake del rootfs de build (patrón 'de gueto', como gcc/cmake). networkmanager-qt 6.27.0 (b5850a40) SELLA. Hallazgo: libKF6NetworkManagerQt.so NO enlaza libnm — sólo Qt6Network/DBus/Core. libnm es dep de BUILD (headers/enums); el runtime es D-Bus puro. Confirma el comentario original de la receta. Próximo: plasma-nm (el applet). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
4e02422680 |
kde/Plasma: glib-shared + pcre2-shared — DEUDA CAPA 0 'glib shared-PIC' SALDADA
La deuda más arrastrada del ADR 0011: glib canónico es -Ddefault_library=static --prefer-static (sólo .a) ⇒ no enlaza en un .so; por eso plasma-workspace tuvo que parchear NetworkManagerQt a opcional (esquivando el rabbit-hole libnm→glib). glib-shared 2.88.1 (dc46a620) produce el set dinámico completo: libglib-2.0.so.0 + libgobject-2.0.so.0 + libgio-2.0.so.0 + libgmodule-2.0.so.0 + libgthread-2.0.so.0 + libgirepository-2.0.so.0. Conserva los switches del canónico (tests/nls/libmount/selinux/introspection off) — sólo cambia el modo de librería, sin arrastrar deps nuevas. pcre2-shared 10.47 (f254abaa) era el prerrequisito: el pcre2 canónico es --disable-shared SIN --with-pic ⇒ su .a no entra en libglib.so. compiler=gcc como el canónico (su comentario advierte que zig-cc MISCOMPILA libs C, patrón file/jq); el .so es ABI-compatible con los consumidores zig. libffi NO necesitó variante: ya usa --with-pic. Cierre verificado: libglib-2.0.so.0 → libpcre2-8.so.0; libffi PIC queda embebido estático. Destraba: libnm (NetworkManager→plasma-nm), polkit, xdg-desktop-portal, gstreamer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
324870e566 |
kde/Plasma: tanda de 5 apps ligeras (9-13) — kcharselect/kfind/kruler/kdf/kwalletmanager
CERO recetas nuevas: las 5 usan sólo deps ya selladas. Binarios verificados en los artefactos. kcharselect da2ea71b selector de caracteres Unicode kfind 9c46fee5 buscador de archivos (+qt5compat por Qt6Core5Compat REQUIRED, +kfilemetadata) kruler f69c1bc8 regla de pantalla (+kstatusnotifieritem) kdf fe681807 espacio en disco → bins kdf + kwikdisk (+kcmutils) kwalletmanager 2d31f0be gestor de billetera → bin kwalletmanager5 (+kwallet/kcmutils) 4/5 sellaron a la primera con el patrón app-KDE estándar. kwalletmanager pidió además degradar DocTools: marca TYPE REQUIRED en set_package_properties ⇒ feature_summary aborta; sed TYPE REQUIRED→OPTIONAL (el mismo patrón que konsole/gwenview; distinto de ark/okular donde DocTools va en el COMPONENTS list). Apps: konsole+dolphin+kate(+kwrite)+kcalc+ark+filelight+gwenview+okular+kcharselect+kfind+kruler+kdf+ kwalletmanager = 13. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
122557615f |
kde/Plasma: okular 25.04.3 (8va app, visor documentos) + poppler 25.02.0 + freetype/fontconfig shared — DEUDA CAPA 0 SALDADA
okular sella (5efc2ad9) con 8 generadores: poppler (PDF) + kimgio + txt + comicbook + fax + fb + dvi + xps. okularGenerator_poppler.so → libpoppler-qt6.so.3 verificado. poppler 25.02.0 (59461aff), Qt6-only: sin QT5/glib/cpp/utils/tests; NSS3/GPGME/LIBCURL/LIBTIFF off y LIBOPENJPEG=none (sin deps selladas; los JPEG2000 embebidos no renderizan, el resto del PDF sí). Cierre libpoppler.so VERIFICADO soberano: libfreetype.so.6 + libfontconfig.so.1 + libjpeg.so.62 + libpng16.so.16 + liblcms2.so.2 + libz.so.1 — sin fugas al sysroot. **DEUDA CAPA 0 'freetype/fontconfig shared-PIC' (marcada pendiente en ADR 0011) SALDADA:** freetype-shared 2.14.3 (76fd1f4b, libfreetype.so.6, --without-harfbuzz corta el ciclo con harfbuzz) + fontconfig-shared 2.18.1 (6ed9e303, libfontconfig.so.1). expat NO necesita variante: el canónico ya usa --with-pic. Las variantes omiten los 3 patches Alpine de rendering (viven en recipes/, copiarlos arriesga colisión de patches homónimos; no afectan el rasterizado que poppler necesita). Fixes okular: FORCE_NOT_REQUIRED_DEPENDENCIES (flag OFICIAL que sugiere el propio feature_summary) para DocTools/Purpose/TIFF/LibSpectre/KExiv2Qt6/DjVuLibre/EPub/Discount/QMobipocket6; +plasma-activities (REQUIRED), +kpty (comicbook), +kwallet (ya sellada). GOTCHA musl durable: synctex_parser.c usa vasprintf (extensión GNU) con -std=c99 ⇒ musl no la declara en modo estricto ⇒ CMAKE_C_FLAGS=-D_GNU_SOURCE. Apps: konsole+dolphin+kate+kcalc+ark+filelight+gwenview+okular. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
31fe5eb937 |
kde/Plasma: gwenview 25.04.3 (7ma app, visor imágenes) + phonon/exiv2 + shared image libs + fix zlib versionado
gwenview sella (1d2bb09d). NEEDED verificado: libexiv2.so.28 + libjpeg.so.62 + libpng16.so.16 + liblcms2.so.2 + libphonon4qt6.so.4. Deps nuevas: phonon 4.12.0 (f0cdba38, multimedia REQUIRED, recorte Qt6-mín) + exiv2 0.28.5 (3eebcce9, EXIF REQUIRED vía FindLibExiv2 de ECM, minimal sólo-zlib + fix -Wno-error=date-time). kImageAnnotator degradado a OPTIONAL. Más deuda Capa 0 (static→shared/PIC): libjpeg-turbo-shared (2c0dca7f, libjpeg.so.8) + libpng-shared (bf8f7724, libpng16.so.16) — el .a canónico no enlaza en gwenviewlib.so. FIX SOBERANÍA zlib versionado: zlib-shared re-hecho con -Wl,--version-script,zlib.map ⇒ ahora exporta compressBound@@ZLIB_1.2.0 e inflateReset2@@ZLIB_1.2.3.4. Qt6 (libQt6Core/Gui) NEEDED esos @tags; el libz.so previo (--whole-archive sin mapa) sólo daba nombres pelados → ld.lld fallaba con --no-allow-shlib-undefined y Qt caía en runtime a la libz de Alpine (fuga). El .so versionado satisface consumidores versionados y no-versionados. Apps: konsole+dolphin+kate+kcalc+ark+filelight+gwenview. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
sergioandClaude Opus 4.8
|
2e0b77852b |
kde/Plasma: filelight 25.04.3 (6ta app, uso de disco) — Qt Quick, sin deps nuevas
filelight sella (46a6ece8) con KIO/I18n/ColorScheme/Config/Crash + QtQuick/QuickControls2 (todo ya sellado). Kirigami + qqc2-desktop-style son estilo RUNTIME. App QML pura. Apps: konsole + dolphin + kate + kcalc + ark + filelight. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |