[Reproducible-builds] Ideas

[Jérémy Bobbio]

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.

I don't understand.

> 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.

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.

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.

> 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?
Especially if we voice the fact that it breaks reproducibility?

> - A different default compression scheme

The default compression scheme would introduce variation from a build to
another? That would be worrisome.

> - Different .deb format revisions

Why would it break the ability to reproduce a build in the same
environment?

-- 
Lunar                                .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20140204/8b89e4e8/attachment.sig>