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 <[email protected]>" > gpgv: Signature made Fri 09 Sep 2016 06:26:07 PM CEST > gpgv: using DSA key 9C59F000777DCC45 > gpgv: Good signature from "Kevin Harwell <[email protected]>" > gpgv: Signature made Fri 09 Sep 2016 07:22:47 PM CEST > gpgv: using DSA key 6CB44E557BD982D8 > gpgv: Good signature from "Richard Mudgett <[email protected]>" > 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 <[email protected]>" > imported > gpg: key 9C59F000777DCC45: public key "Kevin Harwell <[email protected]>" > imported > gpg: key 6CB44E557BD982D8: public key "Richard Mudgett <[email protected]>" > imported > gpg: key 368AB332B59975F3: public key "George Joseph <[email protected]>" > 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 _______________________________________________ devscripts-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
