Launchpad cannot handle ECC or Ed25519 OpenPGP keys

over on https://answers.launchpad.net/launchpad/+question/680583 @cjwatson wrote:

> This is indeed because we're using GnuPG v1. I tried to upgrade to a modern version a while ago but I
> ran into a huge slew of test failures, mainly because of the same sorts of things that Ian Jackson has
> been complaining about for some time (e.g. https://bugs.debian.org/840669). I would like to have
> another go at some point, but it may take a while.

To people who might be inclined to mark this as a duplicate: please note that this is not a duplicate of bug 907675. OpenPGP keys are not SSH keys, and the code involved in handling them is completely separate.

Hate to "bump" bugs, but it's been quite a while and it seems I still can't use EdDSA keys.

I've already revoked my old RSA key and creating another key just for ppa sounds ridiculous for me.

Any plan to revisit this soon?

This issue is also impacting me.

Just spend a huge amount of time wasted on figuring out why I get this stupid cryptic error that it could not import the gpg key.

It is f****** 2022, and still no support for elliptic curve GPG keys? And certainly don't mention in the instructions that this is a limitation, and even better don't bother to tell the user when he tries to import the key that it is the "wrong" type.

Thanks!

I've at least added a message to the "Change your OpenPGP keys" page now, noting the limitation and linking to this bug.

Unfortunately it seems likely that we'll need to do some infrastructure upgrades before it's possible to fix this bug. The new bindings in the python3-gpg package are much better in my experience, but I don't know of a reasonable way to get those working on xenial (and we definitely want to stop running on xenial as soon as we can find time for the upgrade).

Launchpad and Keybase are currently the kids who see ECC and then take their toys and go home. :)

sec> ed25519 2022-02-08 [SC] [expires: 2025-02-07]
      96F74575F7C5E84CD3776CAB5ACF93DDB1D667C4
      Card serial no. = xxxx xxxxxx
uid [ultimate] Barry Allard <email address hidden>
ssb# cv25519 2022-02-08 [E] [expires: 2025-02-07]
ssb rsa4096 2022-02-08 [S] [expires: 2025-02-07]
ssb rsa4096 2022-02-08 [E] [expires: 2025-02-07]
ssb rsa4096 2022-02-08 [A]
ssb> rsa2048 2022-06-04 [E] [expires: 2027-06-03]

I did some experimentation with the new GnuPG 2 changes (not yet deployed to production). Only some key types work as yet. I found that an ed25519 key isn't supported by the version of gpgme1.0 that we have in xenial, while xenial's gpg2 failed to import a secp256k1 key with this somewhat mysterious message:

    gpg: key A719B12D: no valid user IDs
    gpg: this may be caused by a missing self-signature
    gpg: Total number processed: 1
    gpg: w/o user IDs: 1

However, a nistp256 key works OK, although we do need to add it to `GPGKeyAlgorithm` before it will actually be possible to add one of those in Launchpad.

You can now at least use nistp256 keys (possibly some other key types too - I didn't exhaustively test all the possibilities). For other ECC types, see my comment #8.

Hopefully this is resolved soon.

ed25519 and rsa4096 are considered recommended standard today.
Policy requirements increasingly force people to upgrade their keys and revoke the old ones, and then you're kind of stuck.

Even if you manage to use a separate dedicated key for the sole purpose of siging source packages for Ubuntu-PPA, how would you prevent other people from accidentally retrieving this key instead or the new real primary key, since it must be uploaded to the Keyservers?

rsa4096 is already supported, so I'm not completely sure why you're mentioning it here.

As for the rest, it looks like it'll be a matter of upgrading our infrastructure from xenial to focal so that we have a suitably non-ancient gnupg/gpgme. We have lots of reasons to want to do this, and we've put in a fair bit of effort recently to make it possible (indeed, porting to gnupg2 turned out to be a prerequisite). The actual upgrade timeline depends on our sysadmins' availability, but we at least now have a ticket in to get the staging upgrade going and we intend to expedite that as much as we can - getting off xenial will make our lives much easier.

Hi @cjwatson, is there any update on the actual timeline you mentioned or have the sysadmins been unavailble since?

Hi Jan-Philipp, we are still waiting on our sysadmin team to get the upgrade process started and we do not have an ETA that we can share at the moment.

is this solved?
I'm can't register to OpenGPG on launcped.

@leejh76 as per #12 it is not.

this is a workaround I found using the first post:
1- export your public key in a file (ex: key.asc)
2- go to https://keyserver.ubuntu.com/pks and submit your public key in text format
3- go to launchpad (https://launchpad.net/<username>/+editpgpkeys) and submit the fingerprint
Now the key should be accepted for validation

Hi @oherau I can confirm this does not work.

#16 doesn't work

When I try to add my ed25519 fingerprint to Launchpad, i get this error ID: OOPS-e173261a359d2fae76cd204232bf3266

EDIT: It could be that the keyserver did not yet provide the key, as the key was just uploaded and not yet visible on the keyserver. After waiting a bit, I can find my key on the keyserver, but the error persist. This time the error ID is: OOPS-56aca45144fad99eb8898110f04c203b.

Hi Peter, since this issue is still open, it is expected to get errors when trying to add ed25519 OpenPGP keys.