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
`. `'`
`-
signature.asc
Description: Digital signature
