Files
sergioandClaude Opus 5 346cd59706 licencias: campo license en la receta — de 0 a 228 de 1141, sin re-hashear nada
La deuda legal bloqueante del SDD 19 §2.1. Medido hoy: **0 de 1141 recetas** declaraban
licencia, no «5 de 771» como decía el informe anterior. Los dos números estaban mal: los
«5» eran falsos positivos de `grep license` (el paquete `addlicense`, el paquete
`cargo-bundle-licenses`, una línea `install .../share/licenses/` y un comentario), y las
recetas son 1141. Contar con `grep -l <palabra>` sobre TOML cuenta comentarios y nombres,
no campos; `scripts/licencias.sh` cuenta el campo de verdad (clave en la raíz, antes del
primer `[table]`).

LO QUE HACE LA DEUDA PAGABLE: `Recipe::hash_inputs` es una LISTA BLANCA — sólo entran
source, compiler, target, link, patches, flags, phases y deps. `license` no entra, igual
que `evidence` y `slots`. Por eso se puede poblar en las recetas YA SELLADAS sin mover un
solo ArtifactHash. Verificado, no supuesto: en 40 recetas modificadas se comparó el hash
con y sin la línea — 40 idénticos, 0 cambiados. Si el campo entrara al hash, declarar la
licencia costaría reconstruir el corpus entero y no se haría nunca. Clavado con el test
`licencia_round_trip_y_no_afecta_el_hash`.

TRAMPA DE TOML: una clave suelta después de un `[table]` pertenece a esa tabla. Puesta al
final del fichero, `license` acaba dentro de `[deps]` y se pierde EN SILENCIO, porque serde
ignora los campos que no conoce — no hay error, simplemente no está. Va arriba, junto a
`name` y `version`; el sembrador la inserta tras `version`.

NO SE ADIVINA. Declarar mal una licencia es peor que dejarla vacía: convierte un hueco
visible en una afirmación falsa. Sólo se puebla desde una tabla curada entrada por entrada
(`docs/licencias-conocidas.tsv`); lo que no tiene evidencia queda vacío y se CUENTA.
Concretamente se descartó el atajo «k* = KDE ⇒ LGPL»: en este catálogo `kail`, `kind`,
`ko`, `kopia`, `krew`, `kustomize`, `kyverno`, `katana`, `kibi`, `kmon` y toda la familia
`kube*` son herramientas Go sin relación con KDE. El nombre no es evidencia.

Quedan 913, casi todas CLIs Go/Rust importados en masa — y ésas sí son automatizables con
evidencia real: Cargo.toml trae el campo `license` y los módulos Go traen su LICENSE en el
árbol. El cierre estructural es capturarlo en la fase de fetch, que ya descarga y extrae
cada tarball, y inyectar el texto en `hammer pack` (aguas abajo del ArtifactHash) en vez de
en la fase install (que sí re-hashearía).

De paso, respaldo-storagebox.sh reordenado por valor irreemplazable y con zstd: medido en
la oficina, el uplink da 8 Mbps iguales por cable y por wifi ⇒ 128 G no caben en una
sentada, así que sube primero el cerebro (estado + repo) y `--partial-dir` hace que cortar
a mitad de un artefacto no tire lo ya subido.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 10:24:11 -04:00

51 lines
3.2 KiB
TOML

# libcap 2.78 — dependencia de build de bwrap (pieza 4 del toolchain hammer-from-source, SDD 11 §7.2b).
#
# bubblewrap usa libcap para soltar/levantar capabilities al armar el sandbox; su `bubblewrap.c` hace
# `#include <sys/capability.h>` y llama `cap_*`. El toolchain Alpine trae el .so runtime pero NO el
# -dev (ni `sys/capability.h` ni `libcap.a`), así que para compilar bwrap estático necesitamos libcap
# construido por hammer y materializado en el sandbox (ver deps.build de bwrap.toml + sandbox.rs).
#
# A diferencia de linux-headers, libcap NO necesita casar byte-a-byte con la de Alpine: es una pieza
# del TOOLCHAIN (se enlaza dentro de bwrap, una herramienta), no un input del 4/4. Cualquier libcap
# funcional sirve mientras bwrap aísle igual. Por eso sin patches de Alpine: build vainilla y listo.
#
# Build estático musl con zig cc. libcap usa un Makefile plano (no autotools): hay que pasar los
# overrides de toolchain por línea de comando y apagar lo que pide deps ausentes:
# GOLANG=no — sin bindings Go (no hay go en el sandbox).
# PAM_CAP=no — sin el módulo PAM (no hay libpam).
# SHARED=no — sólo estático; no generamos .so (bwrap linkea libcap.a).
# BUILD_CC — el compilador HOST para los toolitos generadores (_makenames/mkconst); zig cc igual.
name = "libcap"
version = "2.78"
license = "BSD-3-Clause OR GPL-2.0-only"
[source]
tarball = "https://mirrors.edge.kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.78.tar.gz"
sha256 = "2a2c705e382c413643a458b837575c0eb0989477ab6fb99c87adbe9a259612ad"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "static"
[deps]
build = ["make"]
[build.phases]
# El árbol de libcap detecta como BuildSys::Make ⇒ el compile/install por defecto no pasa los
# overrides de toolchain ni las flags GOLANG/PAM. Override explícito de ambas fases.
#
# ESTÁTICO DE VERDAD (2026-07-17, frente link-static-mentira-libtool):
# libcap NO usa libtool (Makefile plano) ⇒ `-all-static` (flag exclusivo de libtool) no aplica acá.
# La mentira tenía otra causa: `progs/Makefile` **ASIGNA** `LDFLAGS = -Wl,-Bstatic` con sufijo
# `-Wl,-Bdynamic`, y una asignación en el makefile PISA el `LDFLAGS=-static` que el lab exporta por
# `link="static"`. Ese default de upstream significa "estático contra libcap.a del árbol, DINÁMICO
# contra libc" (lo dice su propio comentario) ⇒ capsh/getcap/setcap salían con NEEDED libc.so — la
# musl que zig bundlea, 255B de linker script en el host ⇒ no corrían fuera del sandbox.
# LIBCSTATIC=yes — la palanca que upstream expone justo para esto: entra en la rama que hace
# `LDFLAGS = --static` sin sufijo -Bdynamic (la usa su propio kdebug/test-kernel.sh).
# No pasamos LDFLAGS por línea de comando: eso pisaría la rama entera y volvería a dejar el sufijo.
compile = "make CC='zig cc -mcpu=baseline' BUILD_CC='zig cc -mcpu=baseline' AR='zig ar' RANLIB='zig ranlib' OBJCOPY='zig objcopy' GOLANG=no PAM_CAP=no SHARED=no LIBCSTATIC=yes lib=lib"
install = "make CC='zig cc -mcpu=baseline' BUILD_CC='zig cc -mcpu=baseline' AR='zig ar' RANLIB='zig ranlib' OBJCOPY='zig objcopy' GOLANG=no PAM_CAP=no SHARED=no LIBCSTATIC=yes lib=lib prefix=/usr DESTDIR=/out install"