Files
takana/recipes
Sergio 63c3b31600 servidor: pacha y pacha-secretos suben de pin — «el llavero falló» se contaba como «no hay identidad»
Los dos daemons de `perfil.servidor` leen la seed de identidad del llavero de
sesión, y los dos tragaban el error: `.ok().flatten()` (o un `_ =>`) convierte
«no se pudo preguntar» en «no hay identidad desbloqueada». La primera es un
error de sistema; la segunda se le echa a quien está delante.

Medido en el LXC del worker, con el binario sellado que va en la imagen:
`add_key` funciona y `keyctl(KEYCTL_SEARCH)` da `ENOSYS` (seccomp de
contenedor) ⇒ ahí se puede SEMBRAR y no COSECHAR, y con la seed presente en
`/proc/keys` `pacha-secretos` igual arrancaba diciendo «SIN identidad agora
desbloqueada». Es el mismo `Err` de cualquier sistema sin llavero de kernel.

Y en `pacha-cli` era peor que un mensaje equivocado: con el llavero roto los
dotfiles se guardaban SIN CIFRAR y sin decir una palabra.

Arreglado en tawasuyu (`4f2b5eac7`) con `pacha_llavero::SeedDeSesion` —los tres
estados, con `motivo()` distinto para cada uno— y test en los dos sentidos.
`pacha-secretos` gana además `reason` en `net.tawasuyu.Secretos1`, al lado de
`persistent`, que existía justamente porque «desde afuera es indistinguible».

hash: pacha-secretos b3:1d2946d0 → b3:7599de72 · pacha b3:ea0c664f → b3:916788ae
(las dos suben juntas al mismo commit para pagar UN solo vendoreo de 2,4 G)
2026-09-21 21:24:36 +00:00
..