tine, el sistema de build sobre Buck2 para imagenes de SO verificables

Daan De Meyer y Martin Pitt han publicado tine, un sistema de build construido sobre Buck2. No es un juguete para compilar un par de binarios: nace para producir imagenes de sistema operativo completas y arrancables, con builds herméticos, salida reproducible bit a bit y compatibilidad con herramientas de SBOM y escaneres de seguridad.

El punto de partida del proyecto es una premisa dura: si el sistema operativo tiene que poder verificarse criptograficamente, quien lo construye tiene que arrastrar esas mismas propiedades. Eso condiciona todo lo demás.

Que le piden al sistema de build

La lista de requisitos es larga y explica por que no reutilizaron algo ya hecho. Quieren dependencias de host minimas, hasta el punto de poder correrlo en cualquier entorno sin montar media infraestructura. Quieren fijar cada pieza de software que entra en un producto, pudiendo elegir la distribucion de origen (Fedora, CentOS, Arch, Debian) y reutilizar paquetes donde tenga sentido, pero con margen para divergir de las decisiones de empaquetado upstream cuando haya que reaccionar rapido a una CVE.

A eso suman maquinaria propia para importar, actualizar y fusionar paquetes, y la capacidad de reconstruir el mundo entero bajo demanda, por ejemplo tras subir la version de gcc. Los builds de componentes e imagenes deben correr en un entorno hermetico y dar el mismo resultado bit a bit. Nada de imagenes como caso especial: tine construye imagenes de SO e imagenes sysext de systemd de forma nativa y concurrente.

El modelo de trabajo es un monorepo unico con iteracion de extremo a extremo. Tocar un rpm importado o un componente en Go o Rust tiene que ser construible y testeable en todo el conjunto de imagenes sin commits intermedios ni declaraciones de dependencias enrevesadas. Y los componentes en Go y Rust se construyen desde repositorios externos fijados, como kubernetes o varlink-http-bridge. La cache es obligatoria: reconstruir todo desde cero lleva horas y el desarrollador suele tocar una sola pieza.

Lo que evaluaron antes

No empezaron de cero por gusto. mkosi, cuyo creador y mantenedor esta en el equipo, fue el primer candidato, pero es un framework: sabe hacer imagenes y para lo demas te deja ganchos opacos. Construir varios artefactos en un monorepo no encaja bien ahi. Open Build Service es potente y cubre un catalogo enorme de distribuciones, pero exige un servidor central, no es trivial de autoalojar y no es un sistema de build generico. BuildStream se acerca mas, con su grafo de elementos YAML y su sandbox, pero arrastra dependencias de Python y del host que complican el pinning, y YAML no tiene funciones, lo que acaba en copiar y pegar por el proyecto. Antlir, el constructor de imagenes de Meta sobre Buck2, es opinionado por diseno para el uso interno de Meta.

De ahi sale la eleccion de Buck2 y un lenguaje que llama a funciones de libreria en vez de un fichero de datos. tine se publica como codigo abierto; lo que no ha quedado claro en el anuncio es con que distribuciones arranca ya y cuanto tarda un world rebuild en la practica. Para quien mantiene imagenes de SO, esa cifra es la que decide si merece la pena mirarlo.