gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1373Shell 116Rust 74Markdown 641915 Definiciones

⎇ 551a103e2dd119ec47b28d831074a214c8a080d2 docs/09-trust-model.md Markdown · 96 líneas · 4.0 KB Historia crudo

takana etapa 5b: los 59 docs de diseño, runbooks y ADR 97ceb7241 · Sergio ·

1# SDD 09 — Modelo de confianza
2
3La premisa de compartir en `takana` es **"verificar, no confiar"**: nunca ejecutas un binario
4ajeno; reproduces una receta sobre código fuente público y compruebas que obtienes el mismo
5resultado. Esto sólo funciona si el build es determinista y si el intercambio está firmado y,
6opcionalmente, anclado a un log de transparencia.
7
8## 1. La cadena de confianza
9
10```
11   código fuente público (repo@commit fijado)
12        │  +  patch declarado en el .swm
13        ▼
14   build determinista en TU laboratorio local
15        │  →  artifact_hash reproducible
16        ▼
17   ¿coincide con el expected_hash del autor?
18        ├─ sí  → obtuviste exactamente su binario, sin descargarlo. Confianza derivada del código, no del autor.
19        └─ no  → algo difiere (pin, patch, toolchain). takana te dice qué. No promueves.
20```
21
22El binario del autor **nunca viaja**. Viaja la *receta*. La confianza no está en "el binario de
23sergio es bueno", sino en "el código fuente público + esta transformación produce esto, y lo
24verifiqué yo mismo".
25
26## 2. Determinismo como cimiento
27
28Todo esto descansa en que dos máquinas con la misma entrada produzcan el mismo
29`artifact_hash` ([SDD 02](02-build-lab.md)). Requisitos prácticos de reproducibilidad:
30
31- **Toolchain fijado.** El `zig`/compilador y su versión forman parte del hash de entrada.
32- **Commits fijados.** Nada de `HEAD` ([ADR 0006](adr/0006-pinned-commits.md)).
33- **Sandbox hermético.** Sin red durante el build, sin fugas del host
34  ([SDD 02](02-build-lab.md) §3).
35- **Eliminación de no-determinismo.** Timestamps embebidos, rutas absolutas, orden de archivos,
36  paralelismo no determinista → se normalizan (p. ej. `SOURCE_DATE_EPOCH`, orden estable).
37
38Cuando un build no reproduce, es un **bug a corregir**, no una excepción a tolerar. La
39reproducibilidad bit-a-bit es objetivo, no aspiración.
40
41## 3. Firma del `.swm`
42
43Un `.swm` puede ir firmado (Ed25519). La firma cubre el contenido del manifiesto (base +
44mutations). Sirve para:
45
46- **Autoría:** saber quién publicó la receta.
47- **Integridad:** que no se alteró en tránsito.
48
49La firma **no** sustituye la verificación reproducible — un autor firmado podría declarar un
50`expected_hash` que no corresponde a su patch; por eso `takana apply` **siempre** reproduce y
51compara, firme o no.
52
53## 4. Log de transparencia (visión, opt-in)
54
55Para compartir en comunidad sin un repositorio central de binarios de confianza, los `.swm`
56publicados pueden anclarse a un **log de transparencia append-only** (estilo Sigstore/Rekor):
57
58- cada `.swm` publicado deja una entrada inmutable (hash del manifiesto + firma + timestamp),
59- cualquiera puede auditar la historia: qué se publicó, por quién, cuándo,
60- detecta sustituciones silenciosas y "split-view".
61
62Esto es opt-in y de fase posterior; el modelo base (reproducir + firmar) ya da la garantía
63fuerte: **no ejecutas binarios ajenos**.
64
65## 5. TrustStore local
66
67Claves públicas en las que el usuario confía para *autoría* (no para ejecución):
68
69```
70/var/lib/hammer/trust/
71    sergio.ed25519.pub
72    comunidad-foo.ed25519.pub
73```
74
75`takana apply` reporta el estado de firma (`trusted` / `unknown-key` / `bad-sig` / `unsigned`)
76pero la decisión de promover sigue dependiendo de la **verificación reproducible** + el
77`commit` humano.
78
79## 6. Resumen de garantías
80
81| Amenaza | Mitigación |
82|---|---|
83| Ejecutar binario ajeno malicioso | No se ejecutan binarios ajenos; se reproduce desde fuente |
84| Receta alterada en tránsito | Firma Ed25519 del `.swm` |
85| Build no reproducible / backdoor en toolchain | Toolchain fijado en el hash + determinismo verificado |
86| Sustitución silenciosa en la comunidad | Log de transparencia (opt-in) |
87| Promoción accidental de algo malo | Overlay + `commit` humano explícito |
88
89## 7. Interfaz
90
91```rust
92// takana-core
93pub fn sign_swm(swm: &Swm, key: &Ed25519PrivateKey) -> Signature;
94pub fn verify_swm(swm: &Swm, trust: &TrustStore) -> SigStatus;
95pub fn reproduce_and_compare(swm: &Swm, store: &Store) -> Result<Vec<HashMatch>>;
96```

09-trust-model.md

SDD 09 — Modelo de confianza

La premisa de compartir en takana es "verificar, no confiar": nunca ejecutas un binario ajeno; reproduces una receta sobre código fuente público y compruebas que obtienes el mismo resultado. Esto sólo funciona si el build es determinista y si el intercambio está firmado y, opcionalmente, anclado a un log de transparencia.

1. La cadena de confianza

   código fuente público (repo@commit fijado)
        │  +  patch declarado en el .swm
        ▼
   build determinista en TU laboratorio local
        │  →  artifact_hash reproducible
        ▼
   ¿coincide con el expected_hash del autor?
        ├─ sí  → obtuviste exactamente su binario, sin descargarlo. Confianza derivada del código, no del autor.
        └─ no  → algo difiere (pin, patch, toolchain). takana te dice qué. No promueves.

El binario del autor nunca viaja. Viaja la receta. La confianza no está en "el binario de sergio es bueno", sino en "el código fuente público + esta transformación produce esto, y lo verifiqué yo mismo".

2. Determinismo como cimiento

Todo esto descansa en que dos máquinas con la misma entrada produzcan el mismo artifact_hash (SDD 02). Requisitos prácticos de reproducibilidad:

Cuando un build no reproduce, es un bug a corregir, no una excepción a tolerar. La reproducibilidad bit-a-bit es objetivo, no aspiración.

3. Firma del .swm

Un .swm puede ir firmado (Ed25519). La firma cubre el contenido del manifiesto (base + mutations). Sirve para:

La firma no sustituye la verificación reproducible — un autor firmado podría declarar un expected_hash que no corresponde a su patch; por eso takana apply siempre reproduce y compara, firme o no.

4. Log de transparencia (visión, opt-in)

Para compartir en comunidad sin un repositorio central de binarios de confianza, los .swm publicados pueden anclarse a un log de transparencia append-only (estilo Sigstore/Rekor):

Esto es opt-in y de fase posterior; el modelo base (reproducir + firmar) ya da la garantía fuerte: no ejecutas binarios ajenos.

5. TrustStore local

Claves públicas en las que el usuario confía para autoría (no para ejecución):

/var/lib/hammer/trust/
    sergio.ed25519.pub
    comunidad-foo.ed25519.pub

takana apply reporta el estado de firma (trusted / unknown-key / bad-sig / unsigned) pero la decisión de promover sigue dependiendo de la verificación reproducible + el commit humano.

6. Resumen de garantías

AmenazaMitigación
Ejecutar binario ajeno maliciosoNo se ejecutan binarios ajenos; se reproduce desde fuente
Receta alterada en tránsitoFirma Ed25519 del .swm
Build no reproducible / backdoor en toolchainToolchain fijado en el hash + determinismo verificado
Sustitución silenciosa en la comunidadLog de transparencia (opt-in)
Promoción accidental de algo maloOverlay + commit humano explícito

7. Interfaz

// takana-core
pub fn sign_swm(swm: &Swm, key: &Ed25519PrivateKey) -> Signature;
pub fn verify_swm(swm: &Swm, trust: &TrustStore) -> SigStatus;
pub fn reproduce_and_compare(swm: &Swm, store: &Store) -> Result<Vec<HashMatch>>;