Duplicate Debian packages with matching name-version-arch problem

[Simon Josefsson]

Vagrant Cascadian <vagrant at reproducible-builds.org> writes:

> If a package is generally bit-for-bit reproducible, if you rebuild it
> multiple times with different build dependent permutations
> (e.g. PACKAGE_VERSION_ARCH.deb with sha256 123456abcde... and
> PACKAGE_VERSION_ARCH.deb with sha256 abcde123456...) we can verify that
> the different permutations of PACKAGE_VERSION_ARCH.deb do not actually
> affect the build results if it comes out reproducible. So we can "prove"
> that the divergence is "ok" without knowing for sure which package it
> was originally built with...

Indeed - I think the focus on build input versions lead us wrong here:
if the output is reproducible, it doesn't matter what inputs where used.

Knowing a recipe to get to a reproducible build IS important, but there
can be multiple ways to get to the same binary, and any way is okay.

To illustrate, the recipes I use in
https://gitlab.com/debdistutils/verify-reproducible-releases to
reproduce release artifacts is NOT the same that were used to produce
the original artifacts.  Instead, these recipes are written in a way to
make them more likely to be forever reproducible, via Guix time-machine.
The original method only works at a particular moment.

That's why I believe getting the Debian archive to be possible to
rebuild idempotently (that is, entire trixie+N is rebuildable using
trixie+N as the build environment, creating a bit-by-bit identical
trixie+N) is a worthy goal.  If we were to realize that, we know we can
rebuild things reproducibly with a path towards bootstrapping Debian
without relying on old software versions that we will never
realistically be able to rebuild reproducible.

The conclusion for me is that, un-intuitively, bootstrapping Debian
through old package binaries is more work than bootstrapping through
latest package binaries.  Identifying differences compared to a
idempotent rebuild may reveal supply-chain vulnerabilities in older
packages (the trusting trust problem).  Rebuilding the packages we have
in the archive using the same version that were used to build the
packages in the archive (the reproduce.debian.net effort) won't give us
that.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20260107/23b48d38/attachment.sig>