Bug#841910: uscan behaviour on multiple signatures

[Osamu Aoki]

Hi,

This is very interesting report.  I did not implement this feature so it
is a learning experience for me.  Please be patient.

> When there is one signature of a key not listed in
> debian/upstream/signing-key.asc a validation warning is thrown.

This sounds good to me.
 
> asterisk$ uscan  
> uscan: Newest version of asterisk on remote site is 13.11.2, local
> version is 13.10.0~dfsg
>  (mangled local version is 13.10.0)
>  uscan:    => Newer package available from
>        http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-13.11.2.tar.gz
> gpgv: Signature made Fri 09 Sep 2016 06:18:48 PM CEST
> gpgv:                using RSA key 368AB332B59975F3
> gpgv: Good signature from "George Joseph <gjoseph at digium.com>"
> gpgv: Signature made Fri 09 Sep 2016 06:26:07 PM CEST
> gpgv:                using DSA key 9C59F000777DCC45
> gpgv: Good signature from "Kevin Harwell <kharwell at digium.com>"
> gpgv: Signature made Fri 09 Sep 2016 07:22:47 PM CEST
> gpgv:                using DSA key 6CB44E557BD982D8
> gpgv: Good signature from "Richard Mudgett <rmudgett at digium.com>"
> gpgv: Signature made Fri 09 Sep 2016 07:41:46 PM CEST
> gpgv:                using DSA key 8438CBA18D0CAA72
> gpgv: Can't check signature: No public key
> uscan warn: OpenPGP signature did not verify.
> 
> In this case d/u/signing-key.asc contains 
> 
> asterisk$ gpg --import < debian/upstream/signing-key.asc 
> gpg: key DAB29B236B940F89: public key "Joshua Colp <jcolp at joshua-colp.com>" imported
> gpg: key 9C59F000777DCC45: public key "Kevin Harwell <kharwell at digium.com>" imported
> gpg: key 6CB44E557BD982D8: public key "Richard Mudgett <rmudgett at digium.com>" imported
> gpg: key 368AB332B59975F3: public key "George Joseph <gjoseph at digium.com>" imported
> gpg: Total number processed: 4
> gpg:               imported: 4
> 
> DAB29B236B940F89 is in signing-key.asc but there is no signature, and
> there is an additional signature from 8438CBA18D0CAA72

You can check 8438CBA18D0CAA72 key using the web of trust.  Then you can
check signature manually.  As for gbp, you can use "gbp import-orig
...".  Then you can go on life...

> When this happens uscan exits with rc=0, but does not process the file
> further without any meaningful error message. I.e. the DFSG repack
> specified in debian/watch is not executed at all. Exiting rc=0 even
> tricks "gbp import-orig --uscan" into importing the non-dfsg upstream
> tarball into the repo.

Yah, too many layers of tools .. they make things difficult for us to
get out of problematic situation.
 
> I did not find any documentation on how uscan deals with multiple
> signatures and/or multiple keys, but so far it looks like all signatures
> have to be made by keys provided in d/u/signing-key.asc. Additional keys
> in d/u/signing-key.asc are not enforced.

I only see this in code:
  unless(system($havegpgv, '--homedir', '/dev/null',
          '--keyring', $keyring,
          "$destdir/$sigfile", "$destdir/$sigfile_base") >> 8 == 0) {
      uscan_warn("OpenPGP signature did not verify.\n");
      return 1;

In gpgv manpage:

RETURN VALUE
   The  program  returns  0  if everything is fine, 1 if at least one
   signature was bad, and other error codes for fatal errors.

Looks like what you get is the expected behavior.  We require all
signatures to be verified by the known keys contained in
debian/upstream/signing-key.asc.

> IMHO this behaviour does not make any sense. You need to check the
> authenticity of any additional key upstream might use before adding it
> to the repo, you cannot just use one known-good key and ignore the rest.

I do not get your point here.  What do you mean by "rest".  

> This even makes an attack a bit more likely, since control over just one
> key in the set is enough to build and sign an accepted tarball.

We are rejecting tarball as precautionary measure.  So you can make
manual check with your intelligence.  I do not see any security problem
here.

Osamu