2 Commits
Author SHA1 Message Date
Sergio b7d30f2f15 publicar-repo: el vhost, con validación y vuelta atrás — y publicar deja de ser compilar
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.
2026-09-21 19:03:08 +00:00
SergioandClaude Opus 5 c0545ea40c repo: clave de release ESTABLE y un publicador por perfil — se acabó firmar con una clave efímera
`build-repo.sh` generaba una clave nueva en cada corrida si no se le pasaba `KEY=`. Un índice firmado
con una clave que nadie conoce y que cambia cada vez no lo verifica nadie: es decoración. El SDD 19
§3.2 lo dice sin vueltas — la firma sin gestión de claves es teatro.

- `trust/release.ed25519.pub` — la clave PÚBLICA, en el repo, que es donde tiene que estar para que
  un cliente pueda verificar. La privada vive en `~/.config/takana/keys/release.ed25519` (0600),
  fuera del repo, mismo trato que las credenciales del Storage Box.
- `trust/README.md` dice también **lo que esto NO es**: no hay clave raíz fuera de línea, ni
  rotación, ni procedimiento de filtración. Cierra el agujero de la clave efímera, NO el §3.2.
- `scripts/repo-perfil.sh` publica la clausura de un perfil y **aborta si no encuentra la clave**, en
  vez de inventar una. El conjunto sale de `yupana.membresia()` sobre `targets.toml`, la misma fuente
  que usa la imagen ⇒ el repo y la imagen no pueden divergir: son la misma lista.
- Y trae su propia guarda: tras firmar, VERIFICA el índice contra `trust/` y falla si no ancla.

Medido: 88/88 del perfil `servidor` con `expected_hash` anclado, índice firmado que verifica.
Control en los dos sentidos contra el repo servido por la caja:

    --trust ./trust        => "release: trusted (by release)"     ⇒ instala
    --trust <dir vacío>    => "release: unknown-key ... clave no confiada" ⇒ ABORTA

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
2026-09-10 21:33:46 +00:00