SergioandClaude Opus 5
c0545ea40c
`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
trust/ — la raíz de confianza del repositorio de paquetes
Acá vive la clave PÚBLICA con la que se firma el índice del repositorio. La privada no está en
git y no va a estarlo: vive en ~/.config/takana/keys/release.ed25519, modo 0600, fuera del repo —
el mismo trato que las credenciales del Storage Box.
Por qué existe este directorio
Hasta el 2026-09-10 scripts/build-repo.sh firmaba con una clave efímera: si no se le pasaba
KEY=, generaba una nueva en cada corrida. Un índice firmado con una clave que nadie conoce y que
cambia en cada build 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.
Con la clave estable, un cliente puede hacer:
takana install <paquete> --repo <url> --trust <ruta a este dir> --require-signed
y eso falla si el índice no está firmado por esta clave. Que falle es el punto.
⚠ Lo que esto NO es todavía
Esto cierra el agujero de la clave efímera. No cierra el SDD 19 §3.2, que pide tres cosas más y ninguna existe:
- Una clave raíz FUERA DE LÍNEA que firme a las de release. Hoy hay un solo nivel: si esta clave se filtra, no hay nada por encima que permita revocarla y emitir otra.
- Rotación: ningún procedimiento escrito de cómo se reemplaza, ni clientes que sepan aceptar más de una clave durante la transición.
- Qué hacer si se filtra: sin lo anterior, la respuesta honesta hoy es «reinstalar la confianza a mano en cada cliente», que no escala más allá de nuestras propias máquinas.
Mientras la distribución sea privada (SDD 28 §2, «operativo pero privado») eso es aceptable. Antes de la primera descarga pública, no.
La clave vigente
| fichero | release.ed25519.pub |
| algoritmo | Ed25519 |
| creada | 2026-09-10 |
| pública (b64) | FRrKg+eXlFuCHUzHNMCaN7eJAesFcgVOQI8KD06IXws= |
| privada | ~/.config/takana/keys/release.ed25519 (0600, nunca a git) |