Hi! On Fri, 2017-01-27 at 15:58:32 +0000, Ian Jackson wrote: > Package: dpkg-dev > Version: 1.18.19 > Severity: serious
> >From the changelog: > > * Add support for signed .buildinfo files to dpkg-buildpackage. Add new > -ui and --unsigned-buildinfo options. Closes: #843925 > > This suggests that buildinfo files will now be signed by default. The > manpage and my ad-hoc tests agree. > > Previously runes like > dpkg-buildpackage -uc -b > dpkg-buildpackage -F -uc -us > were known and recommended as ways to build packages locally. > > Now these runes would have to be > dpkg-buildpackage -uc -b -ui > dpkg-buildpackage -F -uc -us -ui I actually realized this while I was waking up today, and brought it up on IRC. My biggest concern was the buildd network, because that is explicitly not signing files from inside the chroots. But due to gnupg not being installed anymore by default (and very few packages at least directly Build-Depending on it), and the buildd chroots not containing any home directory, the signing is not performed anyway. So in that sense the upload was "safe" from the major fallout. And I was then planning on fixing this for .20, after the testing migration as it indeed breaks user's and other tools expectations. > IMO the correct fix is to, by default, sign the buildinfo iff the > .changes are being signed. That way -uc is sufficient. Yes, that's also the conclusion I had arrived at noon, even though that makes the semantics suck a bit, but oh well. The other thing I was planning (and I've done locally), is to add a new --no-sign option which will make this kind of thing future-proof. Thanks, Guillem
