[Reproducible-builds] Ideas

[Stéphane Glondu]

Le 04/02/2014 23:39, Jérémy Bobbio a écrit :
> Again, my proposal is as follow:
> 
>  * Let t_b be the time at which the build starts.
>  * When writing an archive member with a timestamp of t_m:
>    - if t_m >= t_b, record t_b,
>    - if t_m < t_b, record t_m.
> 
> That way, we preserve the timestamp of every files which have been
> copied literally. And for other files, the timestamp should not matter
> because we know they have been created during the build.
> 
> How could this break implicit assumptions?
> 
> The only one I can think of is a software who would perform comparisons
> of timestamps between various files produced by the build system. But I
> really can't find any sensible reason to do anything like that.

Obviously, there is make.

Actually, now that I think about it, I've already experienced the
following scenario:

 - Makefile contains rules to build %.foo from %.bar.
 - Upstream builds all needed %.foo as part of their build system,
   and installs Makefile, %.foo and %.bar, but not what is needed to
   run the %.bar -> %.foo rule.
 - When user installs the package, and runs the Makefile and the
   timestamps are wrong, the Makefile will try to rebuild %.foo and
   fail.

This scenario might break when timestamps after t_b change. I am not
saying that it is common, but I've already seen it (I cannot give a
concrete example right now).

> To a larger extent, any software relying on the timestamp of files in
> `.deb` should be fixed. Because it would mean relying on root never
> calling “touch”. Such assumption does not exist in Debian.

I've noticed the scenario above by accident during a package-building
debugging session. While it was annoying, it looks legitimate to me and
I would be reluctant to support its ban.

What might be (more) acceptable would be to record (in the .changes
file, in your model) all the timestamps produced by a first build, and
set them in subsequent rebuilds.

>> 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
> 
> Debian has been signing metadata so far. Why would we suddently do this?

The current system is fine for the official Debian archive, but I've
always considered it a bug that self-contained, signed, .deb files are
not available out-of-the-box.

> Especially if we voice the fact that it breaks reproducibility?

I believe adding non-reproducible ar members would not harm the original
goal of reproducible builds: the non-reproducible members could just be
copied from what is being reproduced. As an extreme example, the
.changes file itself could be added as an ar member (using checksums of
the other reproducible members instead of the container's).

Concerning the (what I consider a) side-effect of faster maintainer
uploads, it is still achieved if the non-reproducible ar members are
(relatively) small and transmitted.

All in all, I agree with Guillem's objection that the .deb file is the
wrong boundary for reproducibility. Achieving reproducibility of the
current ar members is still a worthwhile goal in my opinion, though.


Cheers,

-- 
Stéphane