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
