El plan de botar busybox decía de sí mismo que el reparto applet→dueño era
«juicio, no medida». Medido contra los 1407 artefactos del store: de los 277
applets vivos, 167 los provee el dueño que el TSV nombra, 31 los provee OTRO
paquete, y 79 no los provee NADIE salvo busybox — 56 más de los 23 previstos.
El hallazgo transversal es que una receta de LIBRERÍA no es un paquete de
HERRAMIENTAS, y build-state no distingue: `xz` figura en SEIS perfiles con el
`usr/bin` VACÍO (su receta pasa --disable-xz --disable-xzdec --disable-scripts,
o sea liblzma y nada más), y `ncurses` instala sólo install.libs/install.includes
⇒ ni clear, ni reset, ni tput. Las dos viajan, las dos dicen `sealed`, y el único
binario que hay adentro de la imagen es el applet de busybox.
Y al revés: `switch_root` y `sulogin` los trae util-linux, `partprobe` lo trae
parted, y `getty` tiene sustituto — `agetty` de util-linux, en los 7 perfiles ⇒
deja de ser ESCRIBIR y pasa a ser migrar el exec de la card. Seis de los 18
huecos de iproute2 (ipaddr iplink ipneigh iproute iprule iptunnel) no son
comandos de nadie: son nombres internos de busybox y se borran del defconfig.
uutils traía 78 applets, no los 90 que el plan le atribuía: el multicall
contestaba `coreutils: unknown program 'chmod'`. Construía con las default
features (feat_common_core) y el resto vive detrás de feat_os_unix_musl, que
cubre exactamente los 25 que faltaban. Construido y verificado contra un store
tirable: 79 → 106 applets, 27 nuevos y CERO perdidos, chmod/uname/id ejecutan, y
`stdbuf` correctamente ausente (por eso la variante _musl y no feat_os_unix:
upstream lo excluye en musl porque necesita un cdylib).
Importaba más de lo que parece: USERLAND_COMPONENTS hidrata uutils DESPUÉS de
busybox para ensombrecerlo, y lo que no existe no ensombrece nada — chmod, chown,
id, uname y stat los seguía dando busybox con el userland Rust instalado encima.
⚠ Dicho en la receta y en el documento: who/users/uptime/pinky compilan contra
los stubs de utmpx de musl y contestan vacío. No es regresión, tampoco es
sustitución.
El censo queda como script (scripts/busybox-censo-proveedores.py) y como dos
columnas del TSV, no como una tabla escrita a mano que vuelva a envejecer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Mientras se escribían el /etc/shells y el `chsh -s /bin/zsh sergio` había un overlay del FHS
abierto —de un `takana install` sin --prefix sin commitear— y las DOS escrituras cayeron dentro,
aunque no tenían nada que ver con ese paquete ni pasaron por takana (un `cat >` y el chsh de
shadow). Medido con `mount --bind /` no recursivo: en el /etc REAL no había shells y sergio seguía
en /bin/bash, mientras la pantalla mostraba las dos cosas hechas. Un discard o un reinicio lo
borraba y nadie se habría enterado hasta el siguiente login.
Resuelto con commit (5 ficheros promocionados: passwd, passwd-, shells, zsh, zsh-5.9). El
desmontaje perezoso del §5.10 se ganó el sueldo ahí mismo: saltó en /bin y en /usr/bin.
La lección, que es más grande que el caso: `install` sin --prefix NO es un experimento acotado a
ese paquete — cambia la semántica de escritura de la máquina entera hasta que alguien commitea o
descarta, y el overlay no avisa por ningún lado. Como mínimo `takana status` debería salir al
entrar, y el `overlay listo` del install no debería leerse como «terminé». Anotado en SDD 28 §5.11.
Pedido tras instalar zsh: «no me funciona chsh». Dos capas, y sólo la primera es un arreglo.
1. /etc/shells NO EXISTÍA en la caja, y shadow rechaza cualquier shell que no esté listado (para un
usuario normal es rechazo duro, no aviso). Escrito con lo que existe, comprobado -x uno por uno,
en vez de copiar la lista de otra distro: un shell listado que no está deja a quien lo elija sin
poder entrar, y eso no se ve hasta el siguiente login. Con eso `chsh -s /bin/zsh sergio` va, y
`su - sergio` entra con zsh 5.9.
2. ⚠ Pero sergio sigue sin poder cambiárselo él mismo: `su sergio -c "chsh …"` ⇒ «Cannot change ID
to root». Los cinco binarios de shadow que necesitan setuid (chsh, passwd, su, chfn, newgrp)
salen del store r-xr-xr-x, porque la receta lleva --disable-account-tools-setuid heredado del
APKBUILD de Alpine (allá los hace setuid el empaquetado, no el configure). Y debajo hay otra
capa: of_tree sólo hashea el bit de EJECUCIÓN (mode & 0o111), así que el modelo de artefactos
hoy no puede ni expresar ni garantizar un setuid — aunque la receta lo pusiera, el hash no lo
cubriría y nadie notaría si se pierde o aparece.
Quitar la bandera no alcanza y no es un arreglo de receta: es una decisión de seguridad. Anotada
en la propia receta y en SDD 28 §5.11, sin decidir.
El comentario va en la cabecera de la receta y NO mueve su hash: comprobado antes y después,
b3:843e9098… las dos veces (los comentarios fuera de [build.phases] no entran en hash_inputs).
scripts/verificar-repro.sh simi en el worker: «✓ simi REPRODUCE», 0
no-determinismos. Queda anotado en docs/state/repro-verificado.tsv con su hash,
que es la clave del libro: si la receta o alguna dep cambia, la entrada deja de
casar y hay que volver a verificar.
Las dos trampas, anotadas en el SDD porque las dos fallan en silencio:
1. --store <tirable> NO sirve para verificar reproducibilidad. Un store vacío da
«Error: io: No such file or directory» a secas —sin decir qué falta— porque las
deps del build no están ahí. El método correcto ya estaba escrito: apartar el
artefacto dentro del MISMO store y reconstruir. Dos corridas perdidas por
inventar un instrumento en vez de leer el que existía.
2. La cosecha BORRA una receta sembrada a mano: siembra hub→worker con
rsync --delete, y el hub del que siembra es gioser, no el clon donde se
trabaja. El worker perdió recipes/simi.toml entre el build y la verificación
(el artefacto sellado sobrevivió, la receta no) y el verificador informó
«REPRODUCEN: 0 · sin artefacto: 0» — o sea nada, porque su primer [ -f ] falla
y salta en silencio.
Comprobado de paso: editar los comentarios de la receta NO cambia el hash
(hash_inputs es una lista explícita de campos). Y el artefacto vive sólo en el
store del worker: sella con PROMOTE=0 y la cosecha baja el manifiesto, no el
store. Promoverlo es otro paso.
b3:46ff6fcf67bd23dece4d130c92855908520200f88ca85981317f81fcc56bb834
Construida con flock -o en dev.gioser.net (el LXC prestado, coste 0). El
artefacto trae dos ficheros: usr/bin/simi y su .hammer/recipe.toml.
Medido sobre el ARTEFACTO, no sobre el build del hub:
- ELF x86-64 estático, stripped, 498.736 bytes
- scripts/static-audit.sh simi: «estáticos de verdad: 1 · MIENTEN: 0», o sea que
el link=static no es una declaración sino un hecho (ese guardián existe porque
libtool lo ignora en silencio en otras recetas)
- banco diferencial, 159 casos contra el ash de busybox: 0 divergencias
(bash: 8, brush: 35)
- latencia 468 us contra 449 us del ash: 1,04x. brush: 1569 us, 3,5x
Y la lección que vale más que el número: el build NATIVO del hub (glibc,
dinámico) daba 865 us, 1,4x el ash. El estático musl baja a 1,04x. Medir el
binario que VIAJA, no el que se compila a mano — la diferencia fue del 35 % y
habría quedado escrita como si fuera del shell.
Sigue sin estar en ningún perfil de targets.toml a propósito: declararla es
meterla en ATTEST_PATHS y eso es frente C, su propia unidad de trabajo.
recipes/simi.toml sigue el patrón de hammerd/netup: crate del workspace a un
commit fijado, zig cc, musl estático, strip_debug. SIN [build.phases]: el
BuildSys::Cargo instala el binario, y el symlink `sh` NO lo pone la receta a
propósito — quién gana como /bin/sh lo decide USERLAND_COMPONENTS en
takana-bootstrap, que es frente C y su propia unidad de trabajo.
El SDD queda con el veredicto (simi 0 divergencias, bash 8, brush 35), el alcance
por consumidor, los siete bugs del camino y las seis cosas que faltan. Con dos
avisos explícitos: lo medido es el build NATIVO del hub (glibc, dinámico) y el
estático musl no se construyó, así que simi no entra en ningún perfil de
targets.toml; y la shell interactiva de getty no está cubierta.
La primera instalación real de un paquete en la caja (`takana install zsh`, sin --prefix) dejó el
sistema A MEDIAS: `commit` desmontó 5 de 7 targets y murió con `target is busy` en /bin, con dos
overlays montados y el estado sin promocionar. La causa no es un fd abierto: los procesos tienen su
EJECUTABLE mapeado desde /bin y /usr/bin —empezando por PID 1, /usr/bin/arje-zero— y un ejecutable
mapeado pin-ea el montaje. En un FHS vivo eso no se puede evitar esperando.
El comentario de `do_umount_lenient` prometía el desmontaje perezoso «desde la Fase 2» y el código
NUNCA pasaba `-l`. Ahora, ante `busy`, reintenta perezoso: desengancha el montaje ya mismo (las
rutas vuelven a resolver al directorio real, que es lo que el promote necesita) y libera cuando el
último proceso que lo miraba se muere; los vivos ven el mismo contenido porque el commit copia el
upper al lower justo después.
Probado en la caja con un paquete nuevo: install tree ⇒ overlay; commit ⇒ WARN del perezoso sobre
/usr/bin y «commit OK — 1 archivo(s) promocionados»; 0 overlays, /usr/bin/tree real, tree v2.3.2.
El SDD 28 §5.10 anota las otras cuatro cosas que ese `sudo takana install zsh` destapó: el repo por
defecto que no existía, el lab que no se encontraba desde /root, el binario del sistema incapaz de
leer los .tkn nuevos, y —la peor— que la instalación queda PARTIDA porque el overlay cubre siete
directorios y /usr/share no es uno: 1296 de los 1331 ficheros fueron directos al FHS real mientras
2 binarios esperaban el commit, y el mensaje decía `apply OK` igual.
Cron horario de root → /usr/local/bin/avisar-actualizaciones, un envoltorio que sólo fija las rutas
de la caja y llama al guion del repo. La lógica no se copia: comprobado en vivo que arreglar el
guion en el clon cambia la salida del cron sin volver a desplegar nada.
⚠ La primera corrida real destapó un defecto del aviso: con la DB de instalados vacía decía «al
día». Es verdad y no dice nada — peor, se lee como «comprobado y correcto» cuando lo cierto es que
no había NADA que comprobar. Un aviso que suena igual cuando vigila que cuando no vigila nada es
cómo se deja de mirar un aviso. Ahora distingue el caso y lo nombra.
Control en la caja con una DB de juguete (un zsh a otro hash): grita «1 con novedad · hash
distinto» y en la segunda corrida calla.
Y dos piezas que faltaban allá: /var/lib/hammer/trust/release.ed25519.pub (el almacén de confianza
por defecto de la CLI, que no existía ⇒ ahora install/outdated verifican sin pasar --trust) y
/usr/local/bin/takana con el arreglo del §5.5. Ojo: el PATH de la caja no incluye /usr/local/bin,
así que un `takana` a secas sigue siendo el del store; el cron usa rutas absolutas.
Pregunta distinta a la de las cards, y el doc lo dice: scripts/ corre en el hub
bajo el bash del anfitrión, así que su superficie sólo obliga el día del
auto-alojamiento. Lo que importa hoy es si algún guion se declara POSIX y no lo
es, porque ése se rompe en la imagen, donde /bin/sh es el ash de busybox.
- 81 POSIX (10.167 líneas), 76 bash (10.269), 21 EMPOTRADOS por heredoc (los
/init que viajan a la imagen, y que hoy nadie parsea), 6 que se hacen source
- los 81 POSIX y los 21 empotrados los parsea el ash: CERO roto
- 48 de los 76 bash parsean tal cual bajo ash; de los 28 que no, 26 lo son por
arrays y nada más. Ése es el presupuesto entero de un sh propio para correr la
herramienta del proyecto
- 27 builtins, 257 órdenes por nombre desnudo y 35 por ruta absoluta; 0 applets
retirados, o sea que este inventario y busybox-vigia.py ahora coinciden
El escáner se extrajo a scripts/lib/sh_analisis.py para no tener dos copias que
divergan (ADR 0019 un piso más abajo). Comprobado que la extracción no cambió la
salida de sh-superficie-cards.py, byte a byte, y que el orden de los empates es
determinista para que sea diffable.
Van anotados los SIETE bugs del instrumento, que es la parte que enseña: los
comentarios sin quitar (89 backticks de prosa en cosecha-cron.sh), shlex
desincronizándose sobre el fichero entero, los cuerpos de heredoc (uno era
Python y aportaba la orden 'p' — sacarlos bajó las externas de 680 a 257), los
patrones de case dando 'init', los cuerpos de $(( )) dando 'i+1', los
descriptores dando '2', y la ruta absoluta confundida con applet. Ninguno se
veía en la salida: los siete daban números plausibles.
`takana install zsh --repo https://repo.gioser.net --trust ./trust --require-signed` ⇒
`release: trusted (by release)`, 1331 ficheros en 0,286 s, zsh 5.9 corriendo. 173 paquetes
anclados, 0 sin ancla, certificado CN=repo.gioser.net de Let's Encrypt.
Tres cosas que sólo se supieron al poder entrar como root, y que el guion ahora sabe:
· `caddy reload` NO funciona acá: el Caddyfile lleva `admin off` y el reload habla por ese admin
(de ahí que el :2019 estuviera siempre cerrado). La recarga real es `arjectl restart caddy` —
caddy es un Ente de arje con Restart{1000,30000}, no un proceso suelto.
· Un restart levanta los 19 dominios o ninguno, así que el guion saca un TESTIGO de la config
previa (acá gitea.gioser.net), espera a que responda, y si no vuelve restaura y revierte.
Comprobado después: los 8 dominios vivos siguen en pie.
· El certificado tarda más que la comprobación: el guion dio «todavía no responde» y la misma URL
daba 200 segundos después. El mensaje ahora manda reintentar antes de ir a leer logs.
Y dos fallos míos, medidos: backticks dentro de comillas y de un heredoc sin entrecomillar se
EJECUTAN (salió un `journalctl: not found` en mitad de un mensaje de ayuda), y `[ -n "$X" ] && echo`
como última orden mata el guion entero bajo `set -e`.
El espejo provisional sin firmar de takana.gioser.net/repo se borró: con el firmado en pie, un
origen sin firma no es un origen.
Tercer bug de la misma card, de la misma familia y el de peor diente: con un
directorio llamado «juan perez» en /home, el $u desnudo se partía en dos
campos, id -u juan perez fallaba, y el || continue saltaba a ese usuario EN
SILENCIO — se quedaba sin su /run/user/<uid>.
- u=$(basename "$h"), chown "$u", "/run/user/$uid"
- id -u izado a uid=$(id -u "$u" 2>/dev/null) || continue: se llamaba cuatro
veces por usuario (una para el test y tres para las órdenes), ahora una. No
era el bug, era la forma limpia de entrecomillarlo — y se ve en la medición,
que pasó de id×4 a id×1
- los dos echo de error, ahora entre comillas. Inocuo hoy (ningún glob en el
texto) y se comprobó que el mensaje y el rc=78 salen idénticos
Medido con el mismo banco de stubs sobre un /home de prueba con «juan perez»,
root y nadie: antes recibía chown sólo root, ahora root y «juan perez». «nadie»
no recibe en ninguno, que es lo correcto — no está en passwd. Parsea en
busybox, bash y brush.
Mientras repo.gioser.net espera su vhost (root), el catálogo queda servido bajo el sitio que Caddy
ya atiende: /work/sergio/gioser-web/takana/repo, escribible sin root y con certificado válido. 173
paquetes; `install zsh` desde la URL pública tarda 0,22 s (1331 ficheros) y el binario corre.
El índice va SIN FIRMA a propósito. La clave de release está en /root/.config/takana/keys y desde la
jaula no se alcanza; firmarlo con otra habría sido peor que no firmarlo, porque una autoría
inventada se lee igual que una real — es la «firma sin gestión de claves» que repo-perfil.sh se
niega a hacer. Se le quitó la firma de la clave de prueba con la que se ensayó. Control:
--require-signed lo rechaza.
Dos cuidados, porque vive dentro del clon de git de otra web: repo/.gitignore con `*` (el directorio
se ignora a sí mismo, así un `git add -A` en gioser-web no se lleva 173 .tkn) y hermanas.py no lo
borra (sólo escribe index.html). Comprobado que el clon de la web sigue limpio.
Se quita con un rm -rf el día que repo.gioser.net sirva el firmado. No cuenta como el segundo
origen del ADR 0014: un origen sin firma no es un origen.
Los dos los encontró scripts/sh-superficie-cards.py al inventariar las órdenes
externas de las cards. La card nació así en su único commit (3b305642): no fue
un accidente de edición posterior.
- awk NR==2{print } → awk 'NR==2{print $4}'
Sin comillas, awk daba error de sintaxis SIEMPRE y el echo final imprimía
«montar-trabajo: /vvv libres», sin el número, en cada arranque.
- grep -q /vvv /proc/mounts → grep -q " /vvv " /proc/mounts (y lo mismo
para /work/sergio)
El patrón desnudo matchea cualquier línea que CONTENGA la subcadena, así que
la comprobación «¿ya está montado?» podía dar verdadero por un /vvv/algo y
saltarse el mount en silencio. Latente: hace falta otra línea con esa
subcadena para que muerda.
Probado corriendo el fragmento entero con /proc/mounts sustituido por un
fichero de prueba y mkdir/chmod/chown/mount/blkid stubbeados — nada mutó la
máquina. Antes: en el escenario del falso positivo NO montaba /vvv. Después:
monta, y el echo trae el número. Parsea en busybox, bash y brush.
Contesta qué tendría que saber hacer un /bin/sh propio para que el producto
arranque, contado sobre el árbol y no sobre POSIX.
- 33 cards en cuatro poblaciones (recetas, bootstrap, servidor, mudanza); 23
ejecutan shell, 10 son exec directo
- el idioma es uno y se repite 18 veces: test … || { echo >&2; exit 78; }; exec …
- NO aparece nunca: if, funciones, ${…}, posicionales, $?, here-docs, subshells,
segundo plano — ni comillas invertidas, que es lo que tumbó a brush en el sandbox
- 8 builtins y 14 órdenes externas; cruzadas con busybox-applets.tsv, CERO
retiradas por el recorte 401 → 277: es el guardián que el plan pedía, y ahora
corre en un segundo
- las 23 parsean idéntico en busybox, bash y brush (banco diferencial, --files)
Hallazgo que hacía falta para medir bien: en una Card el argv va SIN argv[0] —
arje lo pone desde exec (lo dice la card de hammerd). Sin eso, el idioma de la
mudanza (exec=/bin/sh, argv=[-c, …]) desaparecía de la cuenta.
La detección respeta comillas con un escáner de estados: la primera versión
contaba 11 backticks que eran prosa dentro de mensajes de error.
`work_root` sale de `dirname(store)/work`, o sea `/work` con el store en `/store`, y ahí `sources`
y `out` son ENLACES a `/work/sergio/work/…`, que es del usuario. Publicar como root dejaría
directorios de root en su árbol y su siguiente build moriría con un permiso denegado que no
menciona la causa. No es hipotético: root ya congeló el clon de tawasuyu del dueño dejándole 24
entradas suyas dentro del `.git`, y del lado de root no falló nada (ver publicar-webs.sh).
Si corre como root y nadie fijó TAKANA_WORK, lo manda a /var/tmp/takana-publicar-work y lo dice.
Comprobado que el override no mueve el hash: zsh sella en b3:0be3630d… con y sin él.
Y el mensaje final deja de decir «falta el vhost» cuando lo acaba de poner: si se instaló y aun así
no responde, lo que hay que mirar es el certificado, el DNS y el repo, en ese orden.
brush#1396 abierto. Antes de escribirlo apareció que reubeno/brush ya marcaba
el fallo como known_failure en trap.yaml:226 (y :269, :323 para las otras dos
variantes), sin issue que lo siguiera.
Queda anotado porque es método, no anécdota: un known_failure en la suite del
candidato es evidencia de primera y cuesta un gh api mirarla. Buscar en las
PRUEBAS del candidato, no sólo en sus issues, antes de decir «hallazgo nuevo».
Lo que el reporte sí aporta sobre esos TODOs: que las tres variantes son
probablemente un mismo bug (on_exit() sólo lo llaman los puntos de entrada de
nivel superior; el subshell de interp.rs:662-683 clona el shell y devuelve el
exit code sin pasar por ahí), que también pega en pipeline y en segundo plano,
y que falla en silencio con rc intacto.
Dos cosas que el ensayo del guion destapó, las dos medidas:
1. `repo-perfil.sh` NO acotaba el build. `pack --build` es instantáneo con cache-hit y una
compilación entera si el artefacto no está sellado, así que «publicá el repo» se convertía en
silencio en «ponete a compilar el perfil»: la corrida se puso a moler `libnftnl` en una caja de
4 cores que ya estaba a load 46, y después venía `rust`. `build-repo.sh` llevaba `timeout` desde
siempre; el que se corre en producción, no. Ahora BUILD_TIMEOUT (120 s) y SKIP_UNSEALED=1, con
el vencimiento tratado como «no estaba sellado» y no como error. Resultado del perfil entero:
173 anclados, 0 sin ancla, 2 saltados (os-release, rust), sin compilar nada.
2. `--install-vhost` pone el bloque de Caddy sin que haya que editar a mano, pero el orden es lo
único que lo vuelve seguro: copia → añade → `caddy validate` → SÓLO ENTONCES `reload`. Si
validate o reload fallan, restaura la copia y recarga con ella. Un reload con la config rota no
tira el sitio nuevo: tira los 19 de la caja.
Probado en los dos caminos contra un Caddy de juguete (el de la caja no tiene el admin abierto):
con reload bueno, el admin muestra el server nuevo sirviendo el repo y el sitio previo intacto; con
reload fallido, el Caddyfile vuelve byte a byte y no queda rastro del bloque.
Y `repo-perfil.sh` pasa a respetar TAKANA del entorno: la guarda de publicar-repo.sh comprobaba un
binario y se publicaba con otro, que es peor que no tener guarda.
El banco POSIX de 57 casos lo pasa brush 56/57 y aun así no construye una
receta autotools: mide lo que a uno se le ocurrió preguntar. Este pregunta si
el candidato hace LO MISMO que el control sobre el material que hay.
- compara (rc, stdout, árbol de ficheros producido); stderr es aviso, no
divergencia — el texto de error diverge legítimamente
- el árbol es la columna que faltaba: el caso 10 diverge SÓLO ahí, que es la
clase de bug del libtool mal escapado (rc=0, stdout idéntico)
- toda divergencia se confirma re-corriendo control y candidato: separa caso
no determinista de shell inestable de divergencia real
- fuentes: fixtures de regresión, generador de tortura de comillas, las 1130
fases del corpus y configure/libtool reales en sh -n
Medido, 1273 casos en 5,5 s: brush 35 duras, bash 8, y CERO en los 1156 casos
de parseo. El generador saca el #1394 entero sin conocerlo. Hallazgo nuevo:
brush no ejecuta nunca el trap EXIT de un subshell — y eso golpea el frente
del PRODUCTO, donde el veredicto del paso 3 decía que no había evidencia en
contra.
Se ensamblaron dos Stage 1 completos y se arrancaron los dos, para que cualquier
diferencia se atribuya al recorte y no al azar:
base b3:1a3823b4... 400 applets qemu rc=0
recortado b3:3aa8cd2d... 278 applets qemu rc=0
Los dos dan shell y se apagan limpio. El diff de las dos consolas son 35 líneas y
ninguna es funcional: TSC, direcciones del RAMDISK, BogoMIPS, hora del RTC. La única
diferencia real es el conteo de applets desde dentro de la imagen: 410 contra 288.
Verificado en el recortado: arje-zero como PID 1, la seed card carga (la getty llegó
a incarnar), getty -l /bin/sh da prompt y responde, y poweroff -f apaga de verdad
-- uno de los cinco indultados, probado en vivo.
Corrido en el worker con QEMU en TCG: el LXC no expone /dev/kvm. Hubo que instalar
qemu-system-x86-core y reingerir la semilla de Stage 0, que no estaba en ese store y
salió con el mismo hash que el manifiesto ya anotaba.
Es Stage 1, no el producto: product-boot-test.sh sigue pendiente porque al store del
worker le faltan netup, openssh, uutils, findutils-xargs, diffutils y ripgrep.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El nombre está dado de alta en la zona de Hetzner con la convención de la zona (A, ttl 60, la misma
IP que takana/git/gitea/www). Resuelve — comprobado contra Cloudflare; el resolutor de Google aún
servía el NXDOMAIN cacheado, que es negativo de 1 h por el `minimum` del SOA y no un fallo del alta.
⚠ La API vieja de DNS de Hetzner (dns.hetzner.com/api/v1) ya no es la buena y devuelve HTML de la
consola web, que es lo peor que puede devolver: no falla, contesta. Las zonas están hoy en la API de
cloud y las lee el MISMO token de ~/.config/hcloud/cli.toml (gioser.net = zona 986350).
Hoy el nombre resuelve y no sirve nada: falta el vhost, que es root. `publicar-repo.sh` hace la
parte publicable —repo firmado en /srv/repo + verificación contra trust/— y para imprimiendo el
bloque de Caddy en vez de editarlo: esta caja sirve 19 dominios y su Caddyfile ya lleva 20 `.bak`.
Y aborta antes de publicar si el takana de la caja es anterior al arreglo del SDD 28 §5.5 (se
detecta porque no conoce `outdated`): con uno viejo el repo sale con las 16 recetas multi-parche
irreproducibles y 8 paquetes prometiendo un binario que no existe.
El control que agregué en el commit anterior era el natural y estaba mal: publicar el perfil
`servidor` entero con él dejó 65 de 175 paquetes fuera, porque son LIBRERÍAS (zlib, ncurses,
openssl, musl-*, gmp…) que no traen ningún binario y existen para que otros las resuelvan como
dep — un campo que su consumidor ni mira habría tirado un tercio del repo. Lo destapó el barrido,
no el razonamiento: la versión que abortaba pasaba los tests igual.
Ahora: corrige el path si el binario quedó en otro bindir (que es el caso que importa), y si no
hay ninguno lo dice y publica igual.
Medido con el perfil `servidor`: 162 publicados y firmados, 8 con target_bin corregido (bash, sed,
tar, parted, dhcpcd, squid, wpa_supplicant, zsh — todos publicados hasta hoy prometiendo un path
que no existe), 64 sin binario, 12 sin sellar en este store, 1 fallo (os-release, ya conocido).
Contra el repo firmado por HTTP: parted (6 parches + binario en /usr/sbin) instala en 0,17 s y
responde 3.7; bash responde 5.3.0(1).
Queda vivo: `install <librería>` directo sigue fallando tras hidratar (el .swm exige que el
target_bin exista). Hacer el campo opcional toca el formato — su propia unidad de trabajo.
Cerrar el lazo servir→instalar sobre `zsh` (pedido del usuario) destapó dos fallos de la familia
del `strip_debug` del SDD 28 §5.2: cosas que el `.swm` no transportaba fiel y que sólo se ven
cerrando el lazo, no leyendo el código.
1. `pack` CONCATENABA los N parches en el `patch` inline único, y `hash_inputs` mete una entrada
por parche (con `of_inputs` length-prefijado) ⇒ el receptor sellaba en otra dirección y el
`expected_hash` no coincidía NUNCA. Medido: zsh anclado b3:0be3630d…, reproducido b3:d6329a62…
(idéntico al de una copia de la receta con sus 6 parches concatenados a mano). Afectaba a las
16 recetas del corpus con ≥2 parches. Ahora viajan como lista `patches`, en orden, un fichero
por parche del lado del receptor; el `patch` único se sigue leyendo para no invalidar lo
publicado. Regresión con control negativo en swm_bridge.
2. `target_bin` se adivinaba `/usr/bin/{name}`; zsh instala en `/bin` (--bindir=/bin), así que el
paquete prometía un path que el artefacto no tiene y el error salía en el cliente DESPUÉS de
hidratar 1331 ficheros. Con `--build` el artefacto está delante: se comprueba, se corrige
diciéndolo, y si no hay ningún binario con ese nombre se ABORTA al publicar.
Y el verbo que faltaba para «avisame cuándo actualizar»: `takana outdated` compara la DB de
instalados con el índice firmado (por hash, no por versión: una re-publicación con la misma
etiqueta es otro artefacto). No construye, no baja .swm y no actualiza — instalar es verificar.
Medido tras el arreglo: install zsh ⇒ cache-hit del hash anclado, 1331 ficheros en 0,14 s, zsh 5.9
corriendo.
Paso 1 de docs/plan-botar-busybox.md. 124 applets fuera del defconfig: los 105 que
no se reemplazan (dpkg, rpm, httpd, telnetd, ubi*, nand*, i2c*) y 19 cuya función ya
hace otro componente (init/runit -> arje-zero, syslogd/klogd/logread -> hammerd).
Binario de 1.230.976 a 977.096 bytes.
CORRIGE UN ERROR DEL PLAN: arje-zero y hammerd reemplazan la FUNCIÓN, no el COMANDO
-- son un binario cada uno. Por eso 5 indultos: setuidgid (la card de gitea lo
ejecuta), switch_root (el /init del instalador, antes de que arje exista) y
poweroff/halt/reboot (nada más en el corpus apaga la máquina).
scripts/busybox-vigia.py falla si alguien invoca un applet retirado; lee la lista de
la propia receta para que no haya dos que se desincronicen. Su primera versión daba
91 hits y ninguno real: las cuatro reglas que lo bajaron a 0 están documentadas.
El mapa applet->símbolo sale de las líneas //applet: del fuente, no de poner el
nombre en mayúsculas: eso falla en 6 casos medidos, dos de ellos en la lista.
Verificado: 277 applets exactos, los 5 indultados presentes, y zlib-ng, jq y
logrotate reconstruidas y selladas con el busybox recortado -- el sandbox sigue en
pie. Son 3 de las 24 dependientes, no las 24, y el boot de la imagen no se probó.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bajando al config.status que genera el libtool apareció el mecanismo, y es de una
línea: brush aplica a `...` las reglas de $( ). POSIX manda que dentro de comillas
invertidas la barra se ELIMINE cuando precede a $, ` o \ (2.6.3). Que el caso con
$( ) sí esté bien es lo que delata la causa.
Por eso rompe libtool: el case que decide si cada variable necesita escapado evalúa
a cadena vacía bajo brush, así que todas caen en la rama sin escapar. El configure
termina bien; el fichero sale mal escrito.
Se construyó main de hoy (737dd57e, cuatro meses y medio sobre nuestro pin) y
reproduce idéntico los cuatro casos ⇒ adelantar el pin no arregla nada.
Reportado: https://github.com/reubeno/brush/issues/1394
Y la recomendación: no pelear el shell. Los pasos 1, 2 y 5 del plan no dependen de
él y valen 129 applets y dos piezas de userland.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Medido en el worker, con el único cambio de /bin/sh en una copia por hardlinks del
lab (sed/grep/awk siguen siendo busybox) y stores tirables. Control busybox: 3/3
recetas selladas. brush: 0/3.
Lo que pasa: 56/57 del banco POSIX (igual que busybox), 0 rechazos sobre las 1130
fases de shell del corpus, parsea el configure de ffmpeg, funciona como argv[0]=sh
y con el patrón de las cards de arje.
Lo que falla: el configure corre entero pero el libtool que GENERA sale con un
nivel de escapado de menos en 25 líneas, y ese fichero ya no lo parsea ningún
shell. El parser de brush está bien — parsea sin quejarse el libtool del control.
Mecanismo exacto no determinado: echo, sustitución de comando y el propio
func_quote_for_eval de libtool dan idéntico en ambos shells aislados.
Y un dato independiente del bug: 813us de arranque contra 91us de busybox (8,9x),
sobre decenas de miles de shells por configure. El binario son 7,25 MB contra los
1,23 MB del busybox con sus 401 applets.
De paso: brush selló con el mismo hash que traía build-state del otro hub.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El §7.undecies dejó la bóveda declarada y a NADIE capaz de abrirla: ninguna
imagen traía un binario que sembrara `pacha_llavero::SEED_IDENTIDAD`. Esta es
esa unidad.
De las dos formas posibles entra `agora-cli`, y el motivo no es que sea mejor:
el wizard `churay-welcome-llimphi` SÍ tiene binario (medido: `src/main.rs` sin
`[[bin]]`, o sea que cargo lo descubre), pero decide además backend de IA,
dotfiles, fondo de pantalla y chasqui — la experiencia de primer arranque
entera, que no se decide dentro de una unidad del navegador.
⚠ Y antes de poder declararlo apareció lo que lo volvía imposible: sin
`AGORA_PASSPHRASE`, `Sesion::abrir()` caía en la frase de desarrollo
"agora-dev" con un aviso por stderr y un ✓ en pantalla. La cadena que eso toca:
frase → Argon2id → ChaCha20-Poly1305 que cifra la seed → la clave con la que
`boveda` descifra su base. O sea, en una imagen de escritorio, la bóveda de
todo el mundo cerrada con una palabra escrita en el fuente, y nada que falle.
Arreglado en tawasuyu (`fd08dc03a`): variable > terminal (se pregunta, sin eco,
y DOS veces en la génesis, donde un error de tipeo no se nota hasta que la seed
ya no se recupera) > desarrollo sólo si no hay a quién preguntarle. La decisión
vive en una función pura con cuatro tests, probada AL REVÉS: con el brazo
`Preguntar` borrado falla con `left: Desarrollo / right: Preguntar`.
Pin `9967b02c` → `da5fb8968` ⇒ `b3:46529e14`, 1,9 M, sellado en el worker con
la guarda PEGADA al build. Mirado por dentro (regla 3) y probado como
artefacto, con control negativo: `identity new` + `unlock` deja
`user pacha:id:default: 32` en `/proc/keys`, y con la frase equivocada contesta
«autenticación fallida» y NO re-siembra.
El muro del `Cargo.lock` por cuarta vez, con la causa cambiada: esta vez no la
puso quien tocó el lock sino otro agente que metió `shuma-taller` en un
`Cargo.toml`. Cerrado en el worker, donde el registro está completo: +1 línea.
Y el lock del árbol compartido traía otra vez el malo (índice y árbol con dos
versiones distintas, las dos rotas), así que el commit se armó con
`commit-tree` sin pasar por el índice.
Corrección al §7.undecies: el verbo es `agora-cli unlock`, no
`agora-cli identity unlock`.
El guardián de coherencia pasa de SEIS lugares a SIETE, con su cuarto control
negativo; los cuatro, en verde.
Queda: la herencia del llavero de SESIÓN entre procesos hermanos (sin medir —
y `/proc/keys` como root no la mide), y `pacha`/`pacha-secretos` en
`perfil.servidor` con el mismo hueco.
Medido contra el artefacto sellado (401 symlinks) cruzado con build-state.json:
148 applets ya tienen dueño sellado Y en perfil, 125 tienen dueño sellado que no
viaja en ninguna imagen (uutils, brush, findutils, diffutils, arje-zero, hammerd),
y de los 128 sin dueño 105 son basura que se borra.
Dos hallazgos que cambian el plan: busybox entra a los 7 perfiles como dep de BUILD
de 24 recetas, no como raíz de producto en targets.toml; y brush (shell Rust) ya
está sealed, sin validar y sin perfil.
docs/state/busybox-applets.tsv es la tabla applet-por-applet (generada), con 24
parejas marcadas NO-drop-in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sergio