Debian Bug report logs - #852822
signing buildinfo by default breaks compatibility

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: submit@bugs.debian.org

Subject: signing buildinfo by default breaks compatibility

Date: Fri, 27 Jan 2017 15:58:32 +0000

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 <ijackson@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.

Message #10 received at 852822@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 852822@bugs.debian.org

Subject: Re: Bug#852822: signing buildinfo by default breaks compatibility

Date: Sat, 28 Jan 2017 05:59:09 +0100

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

Message #13 received at 852822-submitter@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: 852822-submitter@bugs.debian.org

Subject: Bug#852822 in package dpkg marked as pending

Date: Sat, 28 Jan 2017 06:15:40 +0000

Control: tag 852822 pending

Hi!

Bug #852822 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

    https://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=5124722

---
commit 5124722df07abb3f440221c28bc578ed82844446
Author: Guillem Jover <guillem@debian.org>
Date:   Sat Jan 28 00:04:33 2017 +0100

    dpkg-buildpackage: Make --unsigned-changes not sign .buildinfo either
    
    There was no option to disable signing globally, so many users and
    tools rely on the two existing options to disable it. But with the
    introduction of signed .buildinfo files, there is no way for old tools
    to request the right thing.
    
    Abuse --unsigned-changes to mean not signing .buildinfo either.
    
    Closes: #852822

diff --git a/debian/changelog b/debian/changelog
index 9363b7e..919cc8c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ dpkg (1.18.20) UNRELEASED; urgency=medium
   [ Guillem Jover ]
   * Add a new --no-sign option to dpkg-buildpackage, to make it possible to
     disable all signing in a future-proof way.
+  * Make dpkg-buildpackage --unsigned-changes not sign .buildinfo either.
+    This breaks the expectations of users and tools, because there was no
+    way previously to request no signing at all. Closes: #852822
   * Perl modules:
     - Mask the machine bits for SH and MIPS in the ELF processor flags in
       Dpkg::Shlibs::Objdump. These do not define the ABI, and make the

Message #20 received at 852822-close@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: 852822-close@bugs.debian.org

Subject: Bug#852822: fixed in dpkg 1.18.20

Date: Sat, 28 Jan 2017 06:33:41 +0000

Source: dpkg
Source-Version: 1.18.20

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 852822@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sat, 28 Jan 2017 06:32:53 +0100
Source: dpkg
Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.20
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description:
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 852822
Changes:
 dpkg (1.18.20) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Add a new --no-sign option to dpkg-buildpackage, to make it possible to
     disable all signing in a future-proof way.
   * Make dpkg-buildpackage --unsigned-changes not sign .buildinfo either.
     This breaks the expectations of users and tools, because there was no
     way previously to request no signing at all. Closes: #852822
   * Perl modules:
     - Mask the machine bits for SH and MIPS in the ELF processor flags in
       Dpkg::Shlibs::Objdump. These do not define the ABI, and make the
       objects not match when they should, when looking for shared libraries
       from dpkg-shlibdeps.
     - Encode the ELF ABI as a big-endian byte stream, so that decoding for
       output gives meaningful results.
     - Disable the NFS-unsafe warning on Linux, as using flock() on NFS has
       been safe for some time now. Addresses: #677865 (on Linux)
   * Documentation:
     - Document the Built-For-Profile field in deb-changes(5).
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated man pages translations ]
   * German (Helge Kreutzmann).
Checksums-Sha1:
 19e4d79a084249f0d081692ec283221007489b9d 2032 dpkg_1.18.20.dsc
 abd47591d9f10dc898d9de2d27870cc4482aefcf 4518520 dpkg_1.18.20.tar.xz
 cf0625761a7e02c377b3689d115a574dd56d94ad 7301 dpkg_1.18.20_amd64.buildinfo
Checksums-Sha256:
 86ca96c38c17b4b53fe6dca09be66c3b54bb71681603124d9cd7ccbfb46ae1c7 2032 dpkg_1.18.20.dsc
 b3f7e6ceeb4a6e0276988abad0ba05cba64f34db55e4f96ca811327880e7c7a4 4518520 dpkg_1.18.20.tar.xz
 60e4d1f0c2ca08745d260ccfc5d1419ecb23e864adb323797b5de29c2628487f 7301 dpkg_1.18.20_amd64.buildinfo
Files:
 fffb74e98bee2ffdfbcbfd46ca2e27f3 2032 admin required dpkg_1.18.20.dsc
 83e4c0c1567a458795ea04efb78b9d6e 4518520 admin required dpkg_1.18.20.tar.xz
 de83538edcb4c42a6565167abaf4b169 7301 admin required dpkg_1.18.20_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEETz509DYFDBD1aWV0uXK/PqSuV6MFAliMMv8ACgkQuXK/PqSu
V6PcrQ//VoPeBEcdA8VPuDac4xIb+8mB7ruOvlTam7wglppMp6KQ66+mDJSlHyBF
5Yg8BytQmZ5TXhQokJeeL2llSvAv8R8xMxZLxw0PfeQts6zn54+HpO1bvA9Ey2Cf
+dXx6ikR8Y2i8ySI5GByzG86ynsv0qJXjhraJXZvfRJvNvqnItN2Lku4Yph+f/zc
GWOfFsag3MnCPITiJAMNP+0Y3vMGaoc5z00xdKYxwFXkzR0++XRrqLqRfzFUImob
s8N/PnhYiWgdNpYfGpkH8mYM4OzjOtMoStDONKCrW2tN2AFdZCPxjLtCSVMspjKI
CiKYtAXsquvpHP4YaeI4Y1AkadKM2Bg2tUFD5a04ZYtmpIn4sL/2uBQlPMIwheZz
cGUQe0M90fYy5WkcpgZbdGVLDJsaKYnE+1+xDvZBKXWJWy+W6AC67SShqrYlqY1R
HWinjk5LSyVcMgKVvU0hsfqY0y8SvytPv3CSQEcY6yT8+WJuWD1N7LNRejg3CtwD
wTxhUu6aY1eL/2pY0g5W52ABYFxgcW2d7z/qFFbREczOymAsujT+AL2buV2baiBz
XsBAJTjoKMrj0CULZAHGdWHyeV9P5UIAJCHelEBiGBIy4lmi0oqSivCuLTLim0/W
GQ7ibOkV+QyaxnikttOuoskm6d/k77vqK/uBfh+nue2pC7e07u8=
=YeN5
-----END PGP SIGNATURE-----

Message #25 received at 852822@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Guillem Jover <guillem@debian.org>

Cc: 852822@bugs.debian.org

Subject: Re: Bug#852822: signing buildinfo by default breaks compatibility

Date: Sun, 29 Jan 2017 00:41:05 +0000

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 <ijackson@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.

Send a report that this bug log contains spam.