Arch Linux tiene desde abril de 2026 una imagen Docker reproducible bit a bit, verificable por digest. Cualquier build del mismo commit genera exactamente el mismo hash, lo que hace posible auditar de forma independiente que la imagen no fue modificada entre compilación y descarga.
En 30 segundos
- Arch Linux lanzó el tag
reproen Docker Hub el 21 de abril de 2026, con reproducibilidad bit a bit confirmada por igualdad de digest entre builds independientes. - La imagen usa
SOURCE_DATE_EPOCHy strips del keyring de pacman para garantizar el determinismo, lo que significa que necesitás correrpacman-key --init && pacman-key --populate archlinuxantes de instalar paquetes. - Es el segundo hito de reproducibilidad de Arch Linux en 2026: la imagen WSL ya lo había alcanzado meses antes.
- La verificación se hace con
podman inspect --format '{{.Digest}}'o con la herramientadiffocipara análisis más granular. - La imagen estándar
archlinux/archlinux:latestsigue igual; el tagreproes adicional y coexiste.
Qué es una imagen Docker reproducible
Una imagen Docker reproducible es aquella donde dos builds distintos, sobre el mismo código fuente y el mismo punto en el tiempo, producen exactamente el mismo resultado binario. No “parecido”. No “funcionalmente equivalente”. Idéntico byte a byte, con el mismo digest SHA256.
Esto importa para la seguridad de la cadena de suministro (supply chain). Si la imagen que vas a descargar tiene el mismo digest que la que un tercero construyó de forma independiente, podés estar razonablemente seguro de que no hubo modificaciones en el proceso de build, ya sea por un atacante, un error de configuración, o un runner de CI comprometido.
El problema con la mayoría de las imágenes base es que incluyen timestamps, caches de ldconfig y otros artefactos que cambian en cada build aunque el código fuente sea idéntico. Eso hace imposible la comparación por digest.
El hito de Arch Linux en abril de 2026
Según el anuncio del maintainer Robin Candau, la imagen reproducible de Arch Linux está disponible bajo el tag repro en Docker Hub desde el 21 de abril de 2026. No es el primer hito de este tipo para el proyecto: meses antes habían alcanzado la misma reproducibilidad para su imagen WSL.
El anuncio fue también posteado en el mailing list arch-dev-public, el canal oficial donde se discuten decisiones de infraestructura del proyecto.
¿Y qué tan reproducible es “bit a bit”? El criterio es concreto: el digest del OCI manifest es idéntico entre dos builds independientes. No hay margen de interpretación acá. Te puede servir nuestra cobertura de herramientas de desarrollo con acceso limitado.
La limitación principal: pacman keys y cómo resolverla
Acá viene lo bueno (y lo incómodo): para lograr el determinismo en el build, el keyring de pacman tiene que ser removido de la imagen. Eso significa que la imagen repro no puede instalar paquetes directamente al arrancar.
Antes de correr cualquier pacman -S, necesitás regenerar el keyring dentro del contenedor:
pacman-key --init && pacman-key --populate archlinux
Podés hacer esto de forma interactiva la primera vez, o incluirlo en un RUN statement de tu Dockerfile si usás la imagen como base. Para quienes usen Distrobox, el hook de pre-init queda así:
distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
¿Es un workaround? Sí. El anuncio lo reconoce: están buscando una solución técnica que permita incluir las claves sin romper la reproducibilidad. Por ahora, el tag repro queda separado como “primer hito” mientras trabajan en eso. Relacionado: generación automática de assets visuales.
Cómo usar la imagen reproducible en producción
Pullear la imagen es igual que siempre:
docker pull archlinux/archlinux:repro
El tag latest sigue existiendo y no cambia su comportamiento. Los dos coexisten. ¿Cuándo elegir uno u otro?
| Criterio | archlinux:latest | archlinux:repro |
|---|---|---|
| Reproducibilidad | No garantizada | Bit a bit, verificable por digest |
| pacman listo para usar | Sí, desde el arranque | No, requiere init de keyring |
| Auditoría de supply chain | No posible | Posible con diffoci o podman inspect |
| Casos de uso | Dev local, scripts rápidos | CI/CD auditado, pipelines de seguridad |
| Disponible desde | Hace años | Abril 2026 |
Para casos de uso en CI/CD donde la auditoría importa, el tag repro es la opción correcta. Para un contenedor de desarrollo local donde simplemente querés Arch y listo, latest sigue siendo más cómodo.
Implementación técnica: SOURCE_DATE_EPOCH y determinismo
El truco central es la variable de entorno SOURCE_DATE_EPOCH, un estándar del proyecto Reproducible Builds que fija el timestamp de referencia para el build. Con eso, cualquier herramienta que use fechas en sus outputs produce el mismo resultado siempre que el epoch sea idéntico.
Además del epoch, el proceso usa los flags --source-date-epoch y --rewrite-timestamp en las herramientas de empaquetado, y remueve el cache de ldconfig, que es uno de los artefactos que cambia entre builds aunque el contenido real no cambie. El campo org.opencontainers.image.created en el LABEL también se fija al epoch en vez de usar la hora real del build.
Todo esto construye el rootFS de forma determinista, que era el desafío principal según Candau. El proceso reutiliza la misma lógica que usaron para la imagen WSL.
Cómo verificar la reproducibilidad: diffoci y podman inspect
La verificación más básica es comparar el digest entre dos builds:
podman inspect --format '{{.Digest}}' archlinux/archlinux:repro
Si el digest que obtenés vos coincide con el que publica el equipo de Arch Linux, la imagen es idéntica. ¿Alguien verificó esto de forma independiente ya? Todavía no hay reportes públicos de auditoría externa al momento de escribir esto, aunque la documentación para reproducir el build está disponible en el repositorio oficial. Lo explicamos a fondo en orquestación de procesos sin dependencias externas.
Para análisis más profundo, la herramienta diffoci compara dos imágenes OCI capa por capa y muestra exactamente qué difiere (si algo difiere). Es útil cuando el digest no coincide y querés entender por qué.
Impacto en DevOps y seguridad de supply chain
Ponele que tu pipeline de CI arranca desde archlinux:latest. Dos runs en días distintos pueden usar versiones levemente distintas de la imagen base, con timestamps diferentes, layers distintos. No podés saber con certeza si la imagen que está corriendo tu build hoy es la misma de ayer.
Con repro, podés fijar el digest en tu Dockerfile:
FROM archlinux/archlinux:repro@sha256:<digest>
Y verificar que ese digest coincide con una build independiente que vos o un tercero hicieron del mismo commit. Eso cierra una brecha real en la cadena de confianza, especialmente en entornos donde se audita la procedencia del software (SBOM, SLSA, etc.).
Comparado con otras distribuciones base populares: Debian tiene el proyecto Reproducible Builds activo hace años y buena cobertura, Alpine está trabajando en ello, Ubuntu tiene avances parciales. Arch llega a este punto con su imagen Docker de forma oficial recién ahora, pero lo hace con un proceso bien documentado y verificable.
Si tu equipo corre infraestructura en contenedores y el hosting importa, tener una imagen base auditable reduce el riesgo de que alguien meta código malicioso en el proceso de build sin que te des cuenta. Es una capa de defensa, no una solución mágica. Para más detalles técnicos, mirá LLMs para análisis de código e infraestructura.
Errores comunes al trabajar con la imagen reproducible
Intentar instalar paquetes sin inicializar el keyring
Es el error más frecuente. Arrancás un contenedor basado en repro, corrés pacman -S git y falla con errores de firma. La imagen no trae el keyring inicializado por diseño. Antes de cualquier operación de paquetes, necesitás correr pacman-key --init && pacman-key --populate archlinux.
Confundir reproducibilidad con inmutabilidad
Que el build sea reproducible no significa que la imagen no va a cambiar nunca. El tag repro se actualiza igual que latest. Lo que garantiza es que si querés reproducir una versión específica (por digest), podés hacerlo y obtener el mismo resultado. Si querés inmutabilidad, fijá el digest en tu Dockerfile.
Asumir que la reproducibilidad valida el contenido del paquete
La reproducibilidad confirma que la imagen no fue modificada respecto al build oficial. No dice nada sobre si los paquetes que instalás después son seguros. Son dos capas de seguridad distintas. La imagen base es confiable; lo que agregás arriba es tu responsabilidad.
Preguntas Frecuentes
¿Qué es una imagen Docker reproducible?
Es una imagen donde dos builds independientes del mismo código fuente producen exactamente el mismo resultado binario, verificable por digest SHA256 idéntico. Esto permite auditar que la imagen no fue alterada entre la compilación y la descarga.
¿Cómo usar la imagen reproducible de Arch Linux?
Pulleá docker pull archlinux/archlinux:repro y antes de instalar cualquier paquete corrés pacman-key --init && pacman-key --populate archlinux. Si la usás como base en un Dockerfile, agregá ese comando como un RUN statement al inicio.
¿Cuál es la diferencia entre la imagen normal y la reproducible de Arch Linux?
El tag latest tiene pacman listo para usar desde el arranque pero no garantiza reproducibilidad entre builds. El tag repro tiene digest verificable bit a bit pero requiere inicializar el keyring manualmente antes de usar pacman. Ambos coexisten en Docker Hub.
¿Por qué la imagen reproducible de Arch Linux no tiene pacman funcional de entrada?
Para garantizar que el build sea determinista, el keyring de pacman tiene que ser removido de la imagen. Incluirlo generaría artefactos que cambian entre builds. El equipo de Arch Linux está trabajando en una solución técnica para incluir las claves sin romper la reproducibilidad.
¿Cómo verifico que la imagen es realmente reproducible?
Usá podman inspect --format '{{.Digest}}' archlinux/archlinux:repro y comparalo con el digest que obtenés reproduciendo el build vos mismo siguiendo la documentación oficial en el repositorio archlinux-docker. Si los digests coinciden, la imagen es idéntica. Para análisis más profundo, diffoci compara las imágenes capa a capa.
Conclusión
Arch Linux sumó en abril de 2026 una imagen Docker reproducible bit a bit, disponible bajo el tag repro. No es un cambio que afecte a todos los usuarios, pero para equipos que trabajan con pipelines auditados, cumplimiento de supply chain, o entornos donde la procedencia del software importa, es un avance concreto y verificable.
La limitación del keyring es real y hay que trabajar con ella (un par de comandos extra en el Dockerfile). El equipo lo reconoce y lo tiene en radar. Por ahora, el tag repro existe como primer hito de un proceso que claramente va a seguir mejorando.
Si ya usás Arch Linux como imagen base en algún pipeline, vale la pena empezar a experimentar con repro en ambientes no productivos. Y si administrás infraestructura web o contenedores en producción, este tipo de mejoras en la cadena de confianza se complementa bien con un hosting que también tome en serio la seguridad de su plataforma, como donweb.com.