Guillem Jover: > Hi! > > As I've mentioned elsewhere, I've noticed several things with the > current .buildinfo format, even after the cleanup pre-merge, that > I'd like to fix or change so that we can hopefully reach Format 1.0. > > Some of the issues, that bother me: > > * .buildinfo files are not currently signed > > I just need to do that, but given that this is not final I didn't > see it as a big problem when I noticed just after the first release > introducing this. Ximin also filed #843925 about this later on. I think, unless you propose something else as the currently planed OpenPGP "clear text signature", there is consensus about this. > * .buildinfo filename > > Having the buildinfo filename be derived from its contents and the > current date is annoying and makes finding it more difficult, as you > have to scan the .changes file if it's around, but cannot link it > directly otherwise. It also leaves dangling files around when building > the same package multiple times, just because the date increases. If > we have already established that the .buildinfo contents will vary > across different builders anyway, which means the .changes files > contents will too, I don't see why we need to distinguish the > .buildinfo filename generation from the .changes filename. > > So I'd probably prefer to use the same algo as used for .changes > filename generation. I think (but I'm not sure) the motivation for the current version is to reflect that there can be different .buildinfos for the same build product and in contrast to .changes files .buildinfos should not be thrown away. So giving them probably unique filenames seem reasonable. > And move the build date inside the .buildinfo file in a Build-Date > field or similar (as I had for some time on my cleanup branch). I'm not sure what I think about this. One point worth considering when discussing this is that we already include a timestamp in the signature. [...] > * .buildinfo files are not generated when creating source-only uploads > > I should probably check the exact conditions, but it might be worth > including a .buildinfo file if it exists and is in debian/files, even > when doing something like: > > $ dpkg-buildpackage -us -uc --change-option=-S > > because then we could "be sure" the maintainer built something. :) Not sure if I understand all details here, but sounds sensible in general. > * .buildinfo has some issues when including .dsc information > > Only the .dsc file is referenced not all of its contents, it might > be better to match .changes logic here. Also the “source” > pseudo-architecture does not get added to the Architecture field. > I'll just do at least the latter, I'm open for discussion on the > former. The .dsc already describes the source package completely through the checksum references for the rest of the package. OTOH I don't see why adding the rest of the source package would harm. > * Some of the environment variables seem superfluous or leaks > > Several of the envvars are either always set by dpkg-buildpackage > anyway (like SOURCE_DATE_EPOCH, although the user might have set it > explicitly and that will be honored), I would say that's exactly the reason for including it. > or should be irrelevant for > the reproducible build, as we should be fixing packages to make them > impervious to change in their values (LANG, LC_* etc). .buildinfos document the build and are designed [0] to include information about the build which should not be required to reproduce the build artifacts. > Some of which kind of leak information about the build system. > > I'm not extremely fussed about this point though, because this might > still be interesting information to record, but only as long as it > does not leak possibly sensitive build system information. Locales > used might be too revealing perhaps. But then reportbug and similar > leak this and much more so, dunno. Normally I'm all for privacy by default but OTOH given how leaky the build process is (see the work of the last years ;P) anybody concerned about leaks through their builds should/must build in a sanitized environment anyway. > I'll probably do some of the fixes already and bump Format to 0.2 > and after the discussion settles we can perhaps do a 0.3, and see how > it goes, and iterate until it looks good, at which point we'd declare > it 1.0, ideally before the freeze. :) Sounds good, and thanks for your work :] [0]: https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles
Attachment:
signature.asc
Description: OpenPGP digital signature