Arch Linux ahora ofrece imágenes de Docker reproducibles bit por bit

• La reproducibilidad bit por bit significa que, si se compila desde la misma fuente, el resultado es completamente idéntico hasta el nivel de bytes sin importar cuándo, dónde o quién lo compile
  • Para lograrlo, hay que eliminar por completo todos los elementos no deterministas, como marcas de tiempo, caché y metadatos que cambian sutilmente según el entorno de compilación
• Si compilas directamente la imagen de Docker y comparas si el digest (hash) es igual al de la imagen oficial distribuida, cualquiera puede verificar de forma independiente que la imagen publicada no fue alterada: esto es importante desde la perspectiva de la seguridad de la cadena de suministro
• La imagen de Docker de Arch Linux ahora se ofrece en una forma reproducible bit por bit, extendiendo al lado de Docker el mismo hito que se logró hace unos meses con la imagen de WSL
• Esta imagen se distribuye con la etiqueta dedicada repro y, para garantizar la reproducibilidad, es necesario eliminar las claves de pacman de la imagen, por lo que no se puede usar pacman de inmediato
  • Hasta que exista una solución adecuada, esta limitación hace que por ahora se publique como una etiqueta separada
• Para instalar o actualizar paquetes dentro del contenedor, primero hay que ejecutar pacman-key --init && pacman-key --populate archlinux para regenerar el keyring
  • Puede hacerse de forma interactiva en la primera ejecución, o ejecutarse en una instrucción RUN del Dockerfile que use esta imagen como base
  • En Distrobox, se puede manejar con un pre-init hook como distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
• La reproducibilidad bit por bit de la imagen se confirma mediante la coincidencia del digest entre compilaciones, y se verifica con podman inspect --format '{{.Digest}}' <image> y comparaciones con diffoci
• Cómo reproducir esta imagen de Docker puede consultarse en REPRO.md

Implementación y ajustes

• La tarea más difícil fue compilar de forma determinista el rootFS base para la imagen de Docker, y se reutilizó el mismo proceso que la imagen de WSL, que comparte el sistema de compilación del rootFS
  • El commit relacionado de WSL puede verse aquí
• Entre los ajustes específicos para Docker, uno fue configurar SOURCE_DATE_EPOCH y hacer que la etiqueta org.opencontainers.image.created del Dockerfile también lo siguiera
• En la imagen compilada, se eliminó en la etapa del Dockerfile el archivo de caché auxiliar de ldconfig, var/cache/ldconfig/aux-cache, que provocaba no determinismo
• Al usar docker build o podman build, se aplicó normalización de marcas de tiempo con las opciones --source-date-epoch=$SOURCE_DATE_EPOCH y --rewrite-timestamp
  • Como ejemplo, se menciona el problema de que los tiempos en etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/ quedaban registrados de forma distinta entre sí
• Todos los cambios relacionados pueden revisarse con más detalle en el diff del merge request del repositorio archlinux-docker
• Como siguiente paso, se está considerando montar en un servidor un rebuilder para la imagen de Docker, la imagen de WSL y futuras imágenes reproducibles, con recompilaciones automáticas periódicas, verificación de reproducibilidad y publicación de logs y resultados de compilación

[GN⁺]

Comentarios de Hacker News

• Da gusto ver este nivel de confianza
  Corrí Arch Linux en WSL 2 durante casi un año y me fue excelente, y después usé Arch nativo por unos 5 meses y también quedé muy satisfecho
  Sigo usando Arch nativo ahora mismo, y pruebo mis dotfiles con una imagen Docker de Arch sobre un sistema de archivos limpio
  Cuando necesito pruebas de extremo a extremo que incluso monten un entorno de escritorio completo, corro Arch en una VM
  Tengo muchos problemas, pero al menos Arch no es uno de ellos

  • Me pregunto si también hay staged rollout o rollback para cambios en los dotfiles
    Justo estaba buscando una configuración de dotfiles nivel enterprise con métricas de Prometheus y health probes, y esto suena exactamente a eso
  • Gracias por dar soporte a otras distros, y también por compartirlo
    Ni siquiera había pensado que necesitaba esto, pero en cuanto lo vi, lo necesité
  • Me pregunto si también has probado NixOS o flakes
    Si sí, me gustaría escuchar qué te parecieron

• Creo que todos los contenedores Docker debieron haber sido así desde el principio
  Ejecutar apt-get update en la etapa de docker build es casi un antipatrón

  • Aunque si usas https://github.com/reproducible-containers/repro-sources-lis..., sería una excepción
    Lo he usado yo mismo y funcionó bastante bien
  • De cualquier forma, ninguna de las dos opciones es totalmente cómoda
    Si no actualizas, se te acumulan problemas de seguridad conocidos en el contenedor, y si actualizas, se rompe la reproducibilidad
    La reproducibilidad sin duda es genial y también tiene ventajas de seguridad, pero una vez que el contenedor pasa del mes puede empezar a sentirse como un objetivo equivocado, y quizá una vida útil máxima medida en días sea más apropiada
  • Sé que es un antipatrón, pero no sé cuál sería la alternativa cuando necesitas instalar software
    Me pregunto si la idea es bajar código fuente etiquetado y compilarlo todo uno mismo con gcc
  • No estoy de acuerdo con verlo como una regla absoluta
    Los contenedores reproducibles son algo bueno, sí, pero no siempre son necesarios, y hay bastantes casos en los que puedes ejecutar apt-get dentro del contenedor sin preocuparte por la reproducibilidad
  • También se complica más porque muchas distros borran las versiones viejas del repo en cuanto sale una nueva
    Claro, siempre queda la opción de sacarlas del archivo histórico

• Las imágenes reproducibles muchas veces parecen una función que solo da satisfacción emocional en el día a día, pero llega el día en que de verdad la necesitas
  A nosotros nos pasó que dos imágenes que debían ser idénticas terminaron con una diferencia de 3 bytes en el timestamp entre máquinas distintas, y por eso perdimos toda una tarde haciendo bisect en la dirección equivocada
  No es algo vistoso, pero definitivamente fue una victoria valiosa

  • Me da curiosidad cómo una diferencia en el timestamp terminó provocando una falla

• Seguro podría meter algo para que todo el mundo se entere de que uso Arch en mi pipeline de CI/CD
  Supongo que también junto con el dato de que hago Crossfit

  • Me recuerda a este koan
    Si te encuentras con un vegano que hace CrossFit y además es usuario de Arch, ¿qué es lo primero que te va a decir?
  • Nunca he entendido por qué alguien se sentiría orgulloso de no usar Slackware

• Aquí pueden ver información sobre Reproducible Builds
  https://reproducible-builds.org/
  Y la comunidad estrechamente relacionada de Bootstrappable Builds está aquí
  https://bootstrappable.org/

• Me pregunto si sistemas como Arch o Alpine, que son sistemas operativos mutables bien diseñados, podrían terminar superando a largo plazo a algo como NixOS
  Porque los scripts de instalación son más expresivos que un lenguaje de configuración declarativa, y por lo general tampoco son más verbosos

  • En ese caso, mejor usar Guix
    Tienes un lenguaje de configuración declarativa, y al mismo tiempo un lenguaje de programación completo de Turing y cómodo de escribir
  • Me pregunto qué significa exactamente strictly more powerful

• Leí el artículo y se ve bastante bien, pero da la impresión de que mezcla Dockerfile con docker image
  Creo que habría sido más fácil construir directamente el archivo tar de la imagen con algo como nix en vez de usar Dockerfile; claro, sería un poco más de nicho, pero también habría quedado más limpio

• Como detalle menor, creo que sería más correcto usar el término OCI Image
  También funciona perfectamente en podman

  • En esta sección de comentarios ando un poco novato y no sigo todo el contexto, pero esto me pareció un punto bastante revelador

• Mi enorme respeto para quienes hicieron esto realmente posible
  El tiempo y esfuerzo que se necesita para lograr un titular como este es mucho mayor de lo que uno imagina

• Es un tema totalmente aparte, pero esa página tiene una animación donde, durante 1 segundo, casi todos los elementos bajan unos 20 píxeles
  Viendo el layout moverse frente a mis ojos, pensé que iba a destrozar el CLS, pero el CLS real era 0
  Entonces me hizo preguntarme si CLS será una métrica engañosa

  • Eso pasa por tratarse de una animación intencional
    CLS se ocupa de cambios durante el renderizado inicial, así que aunque parezca un desplazamiento del layout, no es del tipo que cuenta para CLS
  • Eso no es un layout shift
    Es movimiento causado por una CSS transition, un cambio predecible, y por eso no se cuenta como layout shift