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
Description: This is a digitally signed message part.