Bug#852822: signing buildinfo by default breaks compatibility

2017-01-28 Thread Ian Jackson
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

2017-01-27 Thread Guillem Jover
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

2017-01-27 Thread Ian Jackson
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 Jackson    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.