Latest release signing key is missing a self-signature

[LZY7977]

Hi there,

The latest release signing key provided through this commit is missing a self-signature.

See following command output:

gpg --keyserver hkps://keys.openpgp.org --recv-keys DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7
gpg: requesting key 0DDBF2B7 from hkps server keys.openpgp.org
gpg: key 0DDBF2B7: 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

Can someone work on fixing this issue?

[BethGriggs]

@LZY7977 I'll take a look and sync with @juanarbol

[targos]

I can't reproduce:

$ gpg --keyserver hkps://keys.openpgp.org --recv-keys DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7

gpg: key C77ABFA00DDBF2B7: public key "Juan José Arboleda <soyjuanarbol@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

[BethGriggs]

I can't reproduce:

Same - and I seem to see signatures:

$ gpg --list-sigs DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7
pub   ed25519 2023-03-03 [SC]
      DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7
uid           [ unknown] Juan José Arboleda <soyjuanarbol@gmail.com>
sig 3        C77ABFA00DDBF2B7 2023-03-03  Juan José Arboleda <soyjuanarbol@gmail.com>
sub   cv25519 2023-03-03 [E]
sig          C77ABFA00DDBF2B7 2023-03-03  Juan José Arboleda <soyjuanarbol@gmail.com>

[LZY7977]

I think I found the issue.

The latest public key is using algorithm 22, which is an unknown algorithm for GPG version 2.0. It seems like that we have to upgrade the GPG version.

gpg --list-packets DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7.asc | grep -A2 "public key packet"

:public key packet:
        version 4, algo 22, created 1677815220, expires 0
        unknown algorithm 22

[hacbrown]

I am also encountering the same issue as @LZY7977. would it be possible to not rely on algorithm 22? I don't see a specific version of gpg called out in https://github.com/nodejs/release-keys , but an OS I would like to use only has 2.0 available

[LZY7977]

Same here as @hacbrown. Could we use algorithms that will work with GPG2.0 for the public key?

[tom-dalton-fanduel]

Having the same problem here, using the latest Amazon Linux 2.

[YamsThePotato]

This was discussed at the recent Release Group meeting. I poked around a bit, but I'm not sure I came to a complete answer and I lack experience with GPG signing. Posting what I found in case someone is able to take it further.

1. Algorithm 22 is EDDSA
Algorithm 22 appears to be EDDSA line 171. From a post above, Juan's signature references (curve) ed25519 which is referenced to EDDSA in multiple places including here

2. GPG 2.0 is end of life, but probably still needs to keep compatible with Node releases
GPG 2.0 appears to be end of life based on the bottom of this page.
2.0's branch doesn't appear to have Algorithm 22/EDSA implemented (which I believe explains this issue) link Or more accurately here as the file structure has changed a bit.

Regarding Amazon Linux 2 (AL2), some internet searching shows some older posts struggling to upgrade GPG on that OS. I didn't try, to validate it's still a problem but I do have some experience with old software versions on Amazon Linux 2, and AWS doesn't generally seem to want to upgrade things like this which would risk not being backwards compatible for other use-cases. Regardless, i'm sure there are other use-cases beyond AL2 where the Node community would want to support GPG2.0.

3. Theory on using latest GPG versions to sign, but using a different (older) algorithm which (for now) is still supported on both GPG 2.0 and latest versions
This is where I got stuck, digging into modern GPG options to select an algorithm to create a key with. GPG appears to support multiple algorithms. I theorize that if one were to use the latest GPG version and generate a signature with an algorithm still supported by GPG2.0, then everyone would be happy. From a hasty comparison, ECDH and ECDSA are both mentioned in 2.0 line 59 and don't have Legacy comments attached on the latest branch line 161. This has some risk of choosing a weak algorithm, but I believe ECDSA is still considered strong (but lacking performance relative to EDDSA), however i wasn't able to find the curve used in GPG 2.0 to make sure it's the same on latest versions. So beyond some hands-on testing to ensure compatibility, this should probably also be reviewed by someone with a bit better knowledge of cryptography to confirm there aren't any inherent weaknesses of using a different algorithm for this use-case which i'm not aware of. I hope this helps.