[Reproducible-builds] Ideas

[Hilko Bengen]

* Jérémy Bobbio:

>> In his talk, Lunar mentioned that some patches for dpkg (tar file order,
>> timestamps) for creating reproducible .deb packages have not been
>> integrated yet. As far as I understand, setting arbitrary timestamps in
>> the .deb files seems to be a controversial feature...
>
> Controversial, I don't know yet. See:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719844#30
> and my final proposal for which I never had an answer:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719844#57

After rereading the discussion in the bug report, I get the impression
that it is going to be hard to make the case for bitwise identical .deb
packages. On one hand, we don't know what implicit assumptions that are
baked into some of the software we ship might be broken if arbitrary
timestamps (or no timestamps) are set in the .deb packages. On the other
hand, Guillem has a point as he talks about the possibility of changes
to the .deb files itself that would break bitwise reproducibility
without affecting the contents of the package that get installed on a
system:

- Future ar members containing gpg signatures
- A different default compression scheme
- Different .deb format revisions

The fundamental question is: What information needs to be factored into
a signature that can be compared? Or, put differently: What information
can be ignored?

Do we really need to compare more than filenames, permissions, and
contents in order to determine if two builds of a given package are
equivalent?

>     My ideal scenario is the following:
>
>      1. I retrieve the .changes file for a package.

>From where would you retrieve the .changes files for a given package,
for instance bash_4.2+dfsg-0.1_amd64.changes (as one would expect for
wheezy)?

>      2. I verify the signature on the .changes.
>      3. I give the .changes to a "rebuild" tool.

If I understand you correctly, the .changes file in your scenario would
contain the relevant information to reproduce the build environment
(versions of all binary packages present). Wouldn't it make more sense
to transport this information in the .deb files themselves?

>      4. The checksum of the .deb listed in the original .changes file
>         and the checksum of the .deb I've just built should match.

Where is the problem in comparing checksums that have been derived in a
different way than just taking the md5/sha1/whatever-sum over the .deb
-- or in comparing a list of checksums instead of just one?

Cheers,
-Hilko