Sergio
63c3b31600
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)
64 lines
4.2 KiB
TOML
64 lines
4.2 KiB
TOML
# pacha-secretos — el guardián de secretos de pacha.
|
|
#
|
|
# ⚠ En gioser corre desde un INODO BORRADO: el binario ya no existe en disco y el proceso vive
|
|
# porque nadie lo mató (SDD 28 §6.34). Reconstruirlo es la única forma de tenerlo del otro lado.
|
|
# Y por lo que hace, su cuenta tiene que ser propia y sin privilegio: no comparte usuario con
|
|
# la telemetría.
|
|
#
|
|
# Receta Cargo contra el monorepo de tawasuyu, pinneada al MISMO commit que `shuma-*` y
|
|
# `puriy-costura`: el árbol de fuentes se comparte por `<dep>-<sha>`, así que un pin distinto es otro
|
|
# vendoreo de 2,4 G. Estática musl con zig-cc — la caja la arranca el init y no puede depender de
|
|
# encontrar un cargador, que es justo lo que le falta al binario glibc de gioser.
|
|
|
|
name = "pacha-secretos"
|
|
version = "0.1.0"
|
|
license = "MIT OR Apache-2.0"
|
|
|
|
# ── ⚠ EL PIN SUBE, Y NO ES EL DE SUS HERMANAS (2026-09-21) ────────────────────────────────────
|
|
# De `23a292863` a `4f2b5eac7`. El motivo es un defecto de HONESTIDAD que este servicio tenía y que
|
|
# no se ve desde ningún guardián de ficheros (SDD 26 §7.terdecies): los lectores de la seed de
|
|
# identidad hacían `.recuperar(…).ok().flatten()`, que convierte **«el llavero de sesión no se pudo
|
|
# consultar»** 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: `add_key` funciona y
|
|
# `keyctl(KEYCTL_SEARCH)` da `ENOSYS`, o sea que ahí se puede SEMBRAR y no COSECHAR — y con la seed
|
|
# presente en `/proc/keys` este daemon igual arrancaba diciendo «SIN identidad agora desbloqueada».
|
|
# Mismo `Err` en cualquier sistema sin llavero de kernel (el caso FreeBSD, `LlaveroError::NoSoportado`).
|
|
#
|
|
# Ahora `pacha-llavero::SeedDeSesion` distingue los TRES estados, el `warn!` dice cuál es, y la
|
|
# interfaz propia `net.tawasuyu.Secretos1` gana `reason` al lado de `persistent` — que existía
|
|
# justamente porque «desde afuera es indistinguible».
|
|
#
|
|
# ⚠ El pin ya NO coincide con el de `puriy-costura`, `shuma-*` y `tejido` (`23a292863`), así que
|
|
# paga un árbol de fuentes propio (~2,4 G: se comparte por `<repo>-<sha>`). Se paga a propósito y se
|
|
# comparte con `recipes/pacha.toml`, que sube al MISMO commit por la misma razón —su `pacha-cli`
|
|
# guardaba los dotfiles SIN CIFRAR, en silencio, cuando el llavero fallaba—, así que las dos usan un
|
|
# solo vendoreo. El día que las hermanas suban, que suban a éste.
|
|
[source]
|
|
repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
|
|
commit = "4f2b5eac779c65eae26d6bfdb26dc5effd7ac695"
|
|
# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
|
|
# RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
|
|
cargo_vendor_dir = ".hammer-cargo-vendor"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
flags = ["-p", "pacha-secretos", "--bin", "pacha-secretos"]
|
|
|
|
# ── EL SERVICIO (SDD 30) ────────────────────────────────────────────────────────────────────────
|
|
# La cuenta la declara `recipes/incoming/pacha.toml` — es la misma, y dos recetas declarando la
|
|
# misma cuenta con distinto uid abortan la imagen a propósito (`takana users --merge`).
|
|
#
|
|
# Su base de datos es EFÍMERA por diseño (en gioser: `/tmp/pacha-secretos-efimero-<pid>/db`), así
|
|
# que no hay estado que mudar: lo que sí viaja es el log de estado en `~/.local/state/tawasuyu/`.
|
|
[[service]]
|
|
label = "pacha-secretos"
|
|
id = "01M2EKDA00PACHA5ECRET05X12"
|
|
exec = "/bin/busybox"
|
|
argv = ["sh", "-c", "/bin/grep -q '^pacha:' /etc/passwd || { echo 'pacha-secretos: falta el usuario `pacha` — lo declara recipes/pacha.toml' >&2; exit 78; }; cd /var/lib/pacha || exit 78; exec /usr/bin/setuidgid pacha /usr/bin/pacha-secretos"]
|
|
envp = [["PATH", "/usr/bin:/bin"], ["HOME", "/var/lib/pacha"], ["USER", "pacha"], ["XDG_RUNTIME_DIR", "/run/pacha"]]
|
|
networking = "full"
|
|
cgroup = "arje.slice/pacha-secretos"
|
|
restart = { initial_ms = 1000, max_ms = 30000 }
|