Arch Linux minimal container userland 100% reproducible - now what?

[kpcyrd]

On 3/26/24 5:03 PM, Michael Schierl via rb-general wrote:
> So we can expect many year/month pairs embedded in manpages that got
> unnoticed since mostly the build happens in the same month? Or have they
> been manually vetted?

The results on reproducible.archlinux.org don't aim to guarantee the 
absence of reproducible builds issues, they instead aim to confirm the 
binary can be built from the given source code and build instructions 
(which is, at least for me, why I'm working on reproducible builds, 
since this means we can take the source code at face value for what's in 
the binaries).

Embedded timestamps are considered bad because they are usually a 
show-stopper for this (and timestamps with second/minute precision still 
are for us). There's a different kind of system that tries to prove the 
absence of reproducible builds issues - I've referred to this as "build 
environment fuzzing" in the past and it's the kind of thing 
tests.reproducible-builds.org does.

These results also still exist for Arch Linux[1] (since 2017), and if 
you're concerned about this you could check over there, but since Arch 
Linux _integrates_ with other eco-systems (instead of re-implementing 
them like Debian tries to), some builds fail to build if the clock is 
too far off, since https certificates would be considered expired. 
There's a lot of `curl -k` going on to work around this, but e.g. cargo 
has no option to "turn off all security", so these packages simply won't 
build on there.

[1]: https://tests.reproducible-builds.org/archlinux/

In late 2019 it turned out to be easier to "do the real thing" instead 
of trying to find more workarounds, and "not having enough 
true-positives" isn't really a problem we're having at the moment. If 
you find a false-negative please shout.

If anybody is bothered by the claims Arch Linux is making they're very 
welcome to run a rebuilder with a clock that is off by 48h (this would 
be interesting to have, but still wouldn't guarantee the absence of 
other reproducible builds issues, like missing Cargo.lock files).

> Apart from Guix pushing bootstrappable builds for quite some time,
> recent builds of Freedesktop SDK (container userland mostly used for
> flatpaks) are fully bootstrapped from stage0 - except for Rust which is
> not boostrapped via mrustc but built using the binary package from 
> upstream.

Is there any public website I could look at for results? According to 
our tests, having reproducible distro tooling isn't enough because 
there's still plenty of opensource software doing silly things in their 
build processes.

> Assuming I wanted to bootstrap some (non-reproducible) Arch setup from
> Freedesktop SDK and then use it to verify the reproducible builds, what
> steps would I have to take?

If you want to bootstrap the 114 packages that are present in 
docker.io/library/archlinux from source, you would need to:

- Build any version of pacman (which is C and shell scripts, but for 
makepkg you might even get away with just the shell scripts)
- Download all 114 buildinfo files for these packages (they are 
contained inside of the package itself)
- Identify all packages and their versions that are referenced in there 
as build dependency
- Build these packages on Freedesktop SDK with `makepkg --nodeps`, this 
disables dependency checks and simply assumes the required 
tools/compilers are going to be in $PATH - the checksums of packages 
built this way are naturally going to be different from the official 
packages but that's ok
- Use the packages you built to setup the build environment that is 
described in each buildinfo file
- Run the build with makepkg and SOURCE_DATE_EPOCH set to the value in 
the buildinfo file

This should result in exact matches of the official packages, but of 
course there are a few things that could go wrong so I can not make any 
guarantees.

Instead of doing the last two steps you could also remove the signature 
checks in archlinux-repro[2] and populate its download cache folder with 
the packages you built yourself, archlinux-repro then takes care of the 
rest.

[2]: https://github.com/archlinux/archlinux-repro

> Has anything like that been tried for Arch? How many dependency loops
> are there in the build dependencies of the packages mentioned above, and
> can they be broken by using packages from Freedesktop SDK?

I'm not aware of anybody having tried this. There wasn't much point in 
trying without having achieved reproducible builds first.

cheers,
kpcyrd