Guillem Jover: > Looking at <git://anonscm.debian.org/reproducible/dpkg.git>. > > Have you seen any actual problem to warrant the «Ensure stable order > of Checksums-* fields» commit? In principle the output order is > preserved from the input one.
I have seen the ordering differ, but I might have misunderstood the source of the problem. Unfortunately, the packages have since been tested again and I did not kept track of them. We can always stumble again on the problem later. > And here's a quickish review of the dpkg-genbuildinfo changes, taking > into account that I'm looking at this as a general tool for recording > the build environment, not specific for just reproducible builds. Guillem, thanks for your review! I had not asked for one yet, because we are still exercising this code and design decision on the archive. But I guess time has come. :) > Some general comments first: > > * It would have been nice to get the .buildinfo stuff up for review > in the debian-dpkg list too (besides the ftp-masters bug 763822). I had hoped for some feedback from ftpmasters first. But ok. :) > * I'm still somewhat unconvinced that having byte-for-byte identical > container binary .deb packages is the ideal minimal reproducible > unit. 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. This is a fair point. Having byte-for-byte identical .deb files does not prevent digital signatures. It only makes the process slighly more complex. One solution is to record the signatures in the buildinfo (or in another build product). It can then be copied as-is during rebuilds. > * Somewhat related to the above point and this new file. Timestamps > in some places (mainly on the actual file metadata, for example in > ar and tar containers) are actually very useful, because as long as > we don't have a stored recording of the build environment, it's the > next "best" approximation to that. Getting rid of those prematurely > makes us miss very valuable information for debugging and similar. > And yes, even replacing the current time with the changelog time is > missing information. This has also been dismissed previously (with, > I'd say, even a bit of contempt!). Sorry if it felt contemptuous. You might have more experience than me about using these information for debugging. Could you explain what you mean by “prematurely” here? I was not expecting the proposed changes for dpkg to be merged before buildinfo files could be kept in the archive. > * I'm not entirely sure if this really makes sense as a different > file, but at least given that it's controlled by dpkg-buildpackage > we can always fold it into dpkg-genchanges if we deem that's a > better course of action. So it seems fine this way for now. dpkg-genbuildinfo as a different file from dpkg-genchanges in the source code or *.buildinfo as different control files from *.changes? > * Some of the information in this file trigger my privacy alarm bells, > for example the Build-Path field. Absolutely. For packages shipping DWARF symbols, this is only making the issue more visible. The initial idea was to push for a canonical build location for Debian packages. Adding `Build-Path` to buildinfo gives us the ability to change this location later on. In any cases, considering the build path as part of the build environment removes several hard to solve issues. Maybe if there's enough people feeling like tackling them, we can revisit this decision. I intend to re-work the code according to your comments in a couple of days. I am only learning Perl, please bear with my beginner's mistakes! :) -- Lunar .''`. lu...@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-
Description: Digital signature
_______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds