any reason why the switch? i worked with pgpy and found it quite promising even though development seems to have stalled recently... i dislike pygpgme because it ties back into gpg, which i consider legacy at this point - it brings just too much cruft with it and weird ways of operating...

pgpy is missing a lot of features supported by gpg, and users have reported problems with PGP keys that won't import into meta.sr.ht, or can't be used to encrypt their emails, etc.

right - you certainly will have trouble with ECC keys for example. i guess if you need wider compatibility, you'll certainly have to switch, in the short term, which is too bad becaues you enter a world of API pain. :/

i'm sorry I wish i had better news.

I ran into meta.sr.ht not accepting my PGP key, which uses ECC (ed25519 + cv25519). The interface will simply say:

This is not a valid PGP key

I wanted to suggest potentially using Go, which has pretty solid crypto libraries in the standard library, if you ever plan to rewrite meta.srt.ht. However, after doing a bit of digging it looks like ed25519 is not supported when I look at the PublicKeyAlgorithm type. Other ECC keys are supported though.

It looks like gpg is using algo 22 for ed25519 (I see this by running gpg --list-packets mypubkey.asc), which isn't listed in iana here: https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-12

I didn't quite realize I may be out of luck as far as support when I created my key... The idea of running gpg as a separate process for this piece seems really clunky though. I wonder what the effort would be to update the Python and/or Go library with support for ECC + ed25519 keys.

I didn't quite realize I may be out of luck as far as support when I created my key... The idea of running gpg as a separate process for this piece seems really clunky though. I wonder what the effort would be to update the Python and/or Go library with support for ECC + ed25519 keys.

The problem is that GPG will keep receiving updates... and any other implementation will keep falling behind. GPG isn't a standard interface.

Hi! Is there any update on this? Is there any workaround?

I am unable to upload my public key, which also utilizes ed25519 + cv25519.

Invalid PGP key format: openpgp: unsupported feature: public key type: 22

This is a shame, as many folks are critical of RSA. My impression is that ECC is becoming the new standard. But, given its lack of support here, I won't be able to take advantage of any encrypted communication with sourcehut.

I've seen the following approach work for other projects that need PGP: write a small set of functions using Sequoia PGP's API, expose that through FFI and use it like built-in functions.

For example the following project uses Sequoia in PHP: https://gitlab.com/willbrowning/anonaddy-sequoia/-/blob/master/README.md#available-functions

And something similar for Perl: https://gitlab.com/teythoon/sequoia-nlnet-encrypt-confirmation

There is no additional process needed, no keyring to keep track of, no junk after the process completes.

The downside is that Sequoia needs entire Rust toolchain to build and that may be an issue here.