Problem validating sign-only GPG key

[Guilherme Salgado]

Found this in the error logs. Don't know how to reproduce, but am pasting here so we don't loose the traceback.

  Module canonical.launchpad.browser.person, line 606, in form_action
    return getattr(self, action)()
  Module canonical.launchpad.browser.person, line 641, in claim_gpg
    self._validateGPG(key)
  Module canonical.launchpad.browser.person, line 778, in _validateGPG
    token.sendGPGValidationRequest(appurl, key, encrypt=True)
  Module canonical.launchpad.database.logintoken, line 81, in sendGPGValidationRequest
    key.fingerprint)
  Module canonical.launchpad.utilities.gpghandler, line 190, in encryptContent
    c.op_encrypt([key], 1, plain, cipher)
  Module pyme.util, line 55, in _funcwrap
    "Invocation of " + name)
  Module pyme.errors, line 46, in errorcheck
    raise GPGMEError(retval, extradata)
GPGMEError: Invocation of gpgme_op_encrypt: source(0), code(1) (0,1)

[Celso Providelo (cprov)]

GPG subkey is missing:

pub 1024D/D3BDA225 created: 2005-04-24 expires: 2007-04-24 trust: -/-
(1). Ante Karamatic <email address hidden>

We can't encrypt anything for this key.

[Celso Providelo (cprov)]

Ok, the correct name of this kind of GPG key is "sign-only", they don´t have subkey, needed to have encryption-fu, so the current workflow can't determine its ownership. Talking with dsilvers, we suspect we should support this kind of key, which is commonly onwed used by debian maintainers to sign packages.
The workflow should be adapted somehow, to verify the ownership of those kind of keys based in its capabilities, i.e., verifyin if it can sign content properly. The preliminary solution should be, when confirmed a key is a sign-only one, instead of try to encrypt content and sent to the owner, we try to send plain text containing the respective token and when verifying the token we should require adittionaly than the LP password a deatached signature of the content sent.

[Daniel Silverstone (dsilvers)]

The workflow would essentially be:

1. Check if encryption subkey is available. If it is, follow the standard flow in place already

2. Send a token URL to the email address (similar to how we validate emails currently)

3. Include in that email the message that we expect to get a clearsigned token to validate the message. Anyone capable of creating a signing-only key will know what that means and how to do it.

4. On the token confirmation page, expect the user to provide their launchpad password and to paste into a textarea the token clearsigned with the key we're trying to validate.

[Christian Reis (kiko)]

Oddly enough, I got a user today who is sending the following key to Launchpad:

http://paste.debian.net/2212
# gpg --list-keys DDE93F54
# pub 1024D/DDE93F54 2005-09-20 [expires: 2007-09-26]
# uid Markus Bergholz (markuman) <email address hidden>
# sub 1024g/B825D25C 2005-09-20 [expires: 2007-09-25]

So he seems to have a subkey, and yet, we still get a failure. His key used to be a sign-only key but he added the subkey later. Is that the problem?

[James Henstridge (jamesh)]

kiko: are you sure that Markus's key change had propagated to our server at the time? If the subkey hadn't propagated, then it would be the same issue. If not, then it might be something else.

You can check what is in the keyserver here: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0xDDE93F54 (replace the key id as appropriate)

[Christian Reis (kiko)]

Thanks, you were right -- his key hadn't validated yet.

[Celso Providelo (cprov)]

Both keys pointed allow encryption now and work properly in LP local instance.
I doubt if it is something related with the production environment and $GNUPGHOME setup, keys looks like old.

[James Henstridge (jamesh)]

Celso: the $GNUPGHOME setup might be the issue. The GPGHandler.retrieveKey() code does the following:

 1. try to get key from local keyring
 2. if that fails, grab it from our keyserver

So if someone tries to add a sign-only key we'll cache that key in the app server's $GNUPGHOME. If the user adds an encryption key, waits for the keyserver to synchronise and tries to add it again, LP will still get the old cached version unless one of the following holds:

 * they hit a different app server (we have two now)
 * the app server process has been restarted (which creates a new $GNUPGHOME)

These two variables could indicate why the problem appears to be intermittent.

[Celso Providelo (cprov)]

Jamesh, Yesterday I did the same investigation and you're absolutelly right, the problem is exactly where you pointed.

Kiko opened a new bug for this issue, bug # 3052. I'm not sure what we can do with this one, because finally we have arguments to proof the validating works, but still having some details to sort out, like mask the GPGME exception when trying to encrypt content to a given key.

IMO, keeping this for better error handling or even creating new one is fine, like a group of tasks to achive robustness to the gpghandler component, see also related stuff in bug #1458 and additionally bug #1457, they need a "manager touch" after this fact.

Another point is that I'm not in condition to sort it out in next two weeks, So anyone faster would be nice, because it's kind of critical.

[James Henstridge (jamesh)]

I just wrote up a summary of the issue here:

  https://wiki.launchpad.canonical.com/ValidatingSignOnlyGpgKeys

This is basically the procedure Daniel outlined above, but there are a few unresolved questions. I've already added can_sign and can_encrypt attributes to the IPymeKey interface in rocketfuel, so we could easily provide a simple error message in the meantime though (as opposed to "Oops").

[James Henstridge (jamesh)]

I've committed the initial support for sign-only PGP keys, but it will miss this week's rollout. So in about a week it should be possible to validate sign-only keys.