launchpad-reviewers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxxxxx>]

Diff comments:

> === modified file 'lib/lp/services/gpg/doc/gpg-signatures.txt'
> --- lib/lp/services/gpg/doc/gpg-signatures.txt	2012-06-29 08:40:05 +0000
> +++ lib/lp/services/gpg/doc/gpg-signatures.txt	2019-03-07 15:39:32 +0000
> @@ -164,7 +168,8 @@
>      >>> gpghandler.getVerifiedSignature(content)
>      Traceback (most recent call last):
>      ...
> -    GPGVerificationError: (7, 9, u'No public key')
> +    GPGKeyDoesNotExistOnServer: GPG key E192C0543B1BB2EB does not exist on the
> +    keyserver.

This is indeed very weird.

What's happening is that gpgme drives gpg to do the verification and parses its status-fd output, specifically the ERRSIG line.  Until quite recently this only had the 64-bit key ID.  This was fixed recently, but after bionic never mind xenial:

  https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=23a714598c247d78cfda46a6dc338b17e17cc194
  https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=478d1650bbef84958ccce439fac982ef57b16cd0

I haven't heard of 64-bit key ID collisions in the wild yet.  If they do happen, then we'll call retrieveKey on the 64-bit key ID, which will call importPublicKey on a blob returned by the keyserver that contains multiple keys, which will raise MoreThanOneGPGKeyFound, so the worst consequence is a denial of service for the owner of an affected key.

Given that, I think it's OK to leave an XXX comment for this, and hopefully we'll be on new enough versions of gnupg and gpgme before 64-bit key ID collisions start happening.  Do you agree?

>  
>  Due to unpredictable behaviour between the production system and
>  the external keyserver, we have a resilient signature verifier,


-- 
https://code.launchpad.net/~cjwatson/launchpad/no-auto-key-retrieve/+merge/364100
Your team Launchpad code reviewers is subscribed to branch lp:launchpad.