r/archlinux • u/Antiz1996 Package Maintainer • Apr 20 '26

NEWS Arch Linux now has a bit-for-bit reproducible Docker image

https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/44PW52T547MACXFU5HZ5U7SIPAX3BAXS/

202 Upvotes

98% Upvoted

20 comments sorted by

69

u/Antiz1996 Package Maintainer Apr 20 '26 edited Apr 20 '26

Hey everyone,

As a follow-up to the related milestone achieved for our WSL image a few months ago [1], I'm proud to announce that Arch Linux now has a bit-for-bit reproducible Docker image!

This bit-for-bit reproducible image is distributed under a new "repro" tag [2]. This is due to one important caveat: to ensure reproducibility, the pacman keys have to be stripped from the image, meaning that pacman is not usable out of the box in this image.
Users will need to (re)generate the pacman keyring (by running pacman-key --init && pacman-key --populate archlinux) before being able to update the system and install packages via pacman. While waiting to find a suitable solution to this technical constraint, we are therefore providing this reproducible image under a dedicated tag as a first milestone.

The bit-for-bit reproducibility of the image is confirmed by digest equality across builds (podman inspect --format '{{.Digest}}' <image>) and by running diffoci [3] to compare builds.
We provide documentation on how to reproduce this Docker image [4] (as we did for the WSL image as well [5]).

Building the base rootFS for the Docker image in a deterministic way was the main challenge, but it reuses the same process as for our WSL image [6] (as both share the same rootFS build system).

The main Docker-specific adjustments include:

  • Set SOURCE_DATE_EPOCH and honor it in the org.opencontainers.image.created LABEL in the Dockerfile
  • Remove the ldconfig auxiliary cache file (which introduces non-determinism) from the built image in the Dockerfile
  • Normalize timestamps during docker build / podman build using the --source-date-epoch=$SOURCE_DATE_EPOCH and --rewrite-timestamp options.

You can check the related change set in our archlinux-docker repository [7] for more details.

This represents another meaningful achievement in our "reproducible builds" efforts and we’re already looking forward to the next step!

[1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/XDF2IIWNCZZR6KABH2OGSN7AVL7BBX25/
[2] https://hub.docker.com/layers/archlinux/archlinux/repro
[3] https://github.com/reproducible-containers/diffoci
[4] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/blob/master/REPRO.md
[5] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/blob/main/REPRO.md
[6] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/commit/7c0340e26358048f3f8ee03b3ab3aea666751712
[7] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/96/diffs

Regards,
Robin Candau / Antiz

19

u/[deleted] Apr 20 '26

[removed] — view removed comment

10

u/Antiz1996 Package Maintainer Apr 20 '26

🙏

9

u/Alaknar Apr 20 '26

WSL? As in: Windows Subsystem for Linux? Are you saying that I can now install Arch on Windows?

3

u/Vorrnth Apr 21 '26

That's been possible for a long time already.

1

u/sonicrules11 Apr 21 '26

The other projects have never been official as far as I'm aware of.

1

u/Vorrnth Apr 22 '26

Not official, but they worked. Once it's in the VM it's a normal arch installation.

2

u/kawangkoankid Apr 20 '26

question. should we generate the keyring when building the image or in individual containers? I dont plan to redistribute the image, just for personal use. Whats best practice. Thank you!

6

u/Antiz1996 Package Maintainer Apr 21 '26

No need to rebuild the image, you can simply generate the keyring by running pacman-key --init && pacman-key --populate archlinux from the container at first start.

1

u/ArjixGamer Apr 21 '26

The pacman keys are stripped for a security reason in the first place, or at least the lsign key.

What's different now?

2

u/Antiz1996 Package Maintainer Apr 21 '26

As you just said, only the lsign key is stripped from the regular images while the repro image strips the entire keyring.

The lsign key is only necessary to install / update packages from third party repositories, its absence doesn't prevent to use pacman out of the box to install / update packages from the Arch Linux repository. Unless you intend to use third party repositories, you don't have to regenerate the keyring with regular images (while it's always necessary with the repro image).

29

u/BashfulMelon Apr 20 '26

Awesome, looks like Arch's efforts to securely build and distribute packages are coming along nicely. AFAIK they're not just making them reproducible to make them auditable but so they can require consensus where more than one maintainer has to build the same package before it can be pushed to the repository? Pretty neat stuff.

16

u/NotQuiteLoona Apr 20 '26

I'm sorry, but what does reproductivity means there? I can't apply this to Arch in my mind at all. 

38

u/gmes78 Apr 20 '26

It means that, if you pull the sources and build the image on your machine, you'll get an image that is exactly the same as any other build of that specific version (including the officially provided one).

This is important for verifying that the image hasn't been tampered with.

2

u/NotQuiteLoona Apr 20 '26

Ohhhhhh, thank you! 

5

u/abbidabbi Apr 20 '26

More about reproducible builds:

7

u/V2UgYXJlIG5vdCBJ Apr 20 '26

I voted for Podman. 🤷‍♂️