[Reproducible-builds] Preliminary review of dpkg-genbuildinfo

[Holger Levsen]

Hi Guillem,

thanks a lot for support (including sharing your critism!) in making dpkg(-
dev) suitable for reproducible builds! Very very much appreciated.

I'll keep my comments brief, as Lunar said most already.

Also please note that we'll be announcing the reproducible builds project (in 
it's preliminary state) on d-d-a very soon (probably on / shortly after this 
coming weekend), for officially inviting everyone to have a project wide 
discussion...

Before that, the edited version (aka: with slides) of the video our FOSDEM 
talk should be ready for download, please ping me privatly if you want the 
only-still-camera shots version earlier than that. The Q+A and the end is 
pretty interesting and you can easily put the slides next to the video if you 
want to watch it like this.

On Sonntag, 1. Februar 2015, Guillem Jover wrote:
>  * I'm still somewhat unconvinced that having byte-for-byte identical
>    container binary .deb packages is the ideal minimal reproducible
>    unit.

I'm getting more and more convinced it is. Cause that is what we really care 
about.

>    This will completely disallow digital signatures embedded in
>    the binary packages or per-executable signatures in their xattr
>    metadata for example, and that seems to me was completely ignored
>    last time around. I'd be very unhappy if at some point reproducible
>    builds were enforced and that'd mean we've painted ourselves into a
>    corner with other potential additions to the .deb that might not be
>    reproducible by design.

I think, not allowing unreproducible fields in .debs is a feature and a nice 
design.

And yes, there has been years work on embedding signatures into debs, but I 
dont see it as a problem that the result of this work is: don't do that, it 
causes $these problems.  Detached signatures are pretty common everywhere.

I'm also not surprised no one thought of this design earlier, as reproducible 
builds as we know them today were pretty much unknown and unthought even just 
two years ago.

Also, regarding embedded signatures, sure they are nice, but once we have 
reproducible builds, they are also _way_ less meaningful, as the 
reproducibility (and the signed source) make a even more useful statement: 
with embedded signatures you still need to trust the signee that this binary 
derived from the source he/she says it derives from. With reproducible builds 
you can independently veriry that the binary indeed comes from this source.
 
>  * Some of the information in this file trigger my privacy alarm bells,
>    for example the Build-Path field.

While I don't really share your concerns here, as I think the situation now is 
worse: tools embedd this private data into binaries and not many people know 
about this. So I think making the build path visible (and explaining why we 
have to do this) is actually a step in the right direction, on the way to the 
right fix: not embedding the build path at all.

But that is a goal rather far away, so if we want reproducible builds anytime 
soon, which given the feedback at FOSDEM I think *many* people wish for, not 
only on Debian, btw, we need to solve this somehow.

That said, I don't want to dismiss your point at all, because I also think 
it's valid and we can make the problem more visible in a less intrusive way:

a.) we don't include the build path in the .buildinfo but instead
b.) we _define_ a canonical location for Debian builds

And then buildds and developers and users who want reproducible packages will 
need to build in that location. Which is practically which we (the 
reproducible builds project) already demand, just that we now codifiy this 
redundantly in every .buildinfo file.

Probably this is a good question to include in the d-d-a mail...


Touching this subject and also subject to RFC on d-d-a: currently non 
reproducibility bugs are wishlist, I hope soon, once the dpkg+debhelper 
(+probably cdbs) changes are in sid, these bugs will become normal bugs.

So developer builds in a different build path or otherwise unreproducbile 
builds should not become policy violations or even important bugs for the 
immediate future, even in my vision ;-) But that said, I certainly hope that 
reproducibility will be at least a release goal for stretch!


cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150204/b38c4dc3/attachment.sig>