Bug#852822: signing buildinfo by default breaks compatibility
Guillem Jover writes ("Re: Bug#852822: signing buildinfo by default breaks compatibility"): > 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. Thanks for fixing it earlier. I didn't do thorough tests, but the change would have broken dgit. Probably the test suite; perhaps the build wrapper methods; and certainly the workflow documentation. > 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. Can you please make a short alias for --no-sign ? Many tasks (particularly ones done by non-dds) involve building packages without signing them. Also, please bear in mind that runes in documentation like dgit-user(7) will live on in people's finger macros for many years. Thanks, Ian. https://manpages.debian.org/testing/dgit/dgit-user.7.en.html -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#852822: signing buildinfo by default breaks compatibility
Hi! On Fri, 2017-01-27 at 15:58:32 +, 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
Bug#852822: signing buildinfo by default breaks compatibility
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 But those runes are not supported by dpkg in jessie. This means that there is no longer a rune for `build this package but do not sign anything' that will work both before and after this change. IMO that is a serious regression. IMO the correct fix is to, by default, sign the buildinfo iff the .changes are being signed. That way -uc is sufficient. Thanks for your attention. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.