sergioandClaude Opus 4.8
8bf1623044
Arranque del proyecto hammer (distro AI-nativa: laboratorio funcional en el sótano, terminal mutable clásica arriba, integración de IA programadora). - Workspace Rust (compila, tests verdes): hammer-core, hammer-build, hammer-cli (bin `hammer`), hammerd. - SDDs 00-10 + 6 ADRs en docs/ con toda la arquitectura. - Esqueletos navegables mapeados a las fases del roadmap; Fase 0/1 listas para implementar el sandbox real. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
97 lines
4.0 KiB
Markdown
97 lines
4.0 KiB
Markdown
# SDD 09 — Modelo de confianza
|
|
|
|
La premisa de compartir en `hammer` 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). hammer 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](02-build-lab.md)). Requisitos prácticos de reproducibilidad:
|
|
|
|
- **Toolchain fijado.** El `zig`/compilador y su versión forman parte del hash de entrada.
|
|
- **Commits fijados.** Nada de `HEAD` ([ADR 0006](adr/0006-pinned-commits.md)).
|
|
- **Sandbox hermético.** Sin red durante el build, sin fugas del host
|
|
([SDD 02](02-build-lab.md) §3).
|
|
- **Eliminación de no-determinismo.** Timestamps embebidos, rutas absolutas, orden de archivos,
|
|
paralelismo no determinista → se normalizan (p. ej. `SOURCE_DATE_EPOCH`, orden estable).
|
|
|
|
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:
|
|
|
|
- **Autoría:** saber quién publicó la receta.
|
|
- **Integridad:** que no se alteró en tránsito.
|
|
|
|
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 `hammer 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):
|
|
|
|
- cada `.swm` publicado deja una entrada inmutable (hash del manifiesto + firma + timestamp),
|
|
- cualquiera puede auditar la historia: qué se publicó, por quién, cuándo,
|
|
- detecta sustituciones silenciosas y "split-view".
|
|
|
|
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
|
|
```
|
|
|
|
`hammer 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
|
|
|
|
| Amenaza | Mitigación |
|
|
|---|---|
|
|
| Ejecutar binario ajeno malicioso | No se ejecutan binarios ajenos; se reproduce desde fuente |
|
|
| Receta alterada en tránsito | Firma Ed25519 del `.swm` |
|
|
| Build no reproducible / backdoor en toolchain | Toolchain fijado en el hash + determinismo verificado |
|
|
| Sustitución silenciosa en la comunidad | Log de transparencia (opt-in) |
|
|
| Promoción accidental de algo malo | Overlay + `commit` humano explícito |
|
|
|
|
## 7. Interfaz
|
|
|
|
```rust
|
|
// hammer-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>>;
|
|
```
|