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