doc: ensure that GPG key used to sign the latest LTS release (12.6.1), as well as 13.12.0, & 8.16.0 is mentioned in README(.md) (#32559)

[haqer1]

Checklist

• documentation is changed or added
• commit message follows commit guidelines

[addaleax]

@MylesBorins

[haqer1]

I think this should be merged at present because users encounter 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946 key for the latest LTS release. If they won't encounter it for the next LTS release & going forward, then Myles Borins' key could be updated as needed afterwards...

P.S. The point is to make it easier (& less scary) for users.

@MylesBorins

[richardlau]

Assuming the old key was used to sign some previous releases, it should be kept in the README. Maybe move the old key to the "Other keys used to sign some previous releases:" bit below?

[haqer1]

Maybe move the old key to the "Other keys used to sign some previous releases:" bit below?

Yes, both keys have been used. Based on this point, I'd suggest:

1. merging this PR.
2. adding the other keys in "Other keys used to sign some previous releases:"
3. going forward, interchanging the 2 if needed, depending on which key is used for signing the latest LTS releases henceforth.

[haqer1]

FYI: alternative fix-up approach is in #32565 (the 2 are mutually exclusive).

[MylesBorins]

Want to dig in on this a bit because I'm very confused. This is the same key I've been using for a while. I have a primary key and a subkey for signing. The documented key is my primary key, not the subkey... both are present when you examine the tag As you can see below.

[master][master]$ git tag -v v12.16.1
object d3fb1680dccdf374c99e588d2fbe855e14da4b95
type commit
tag v12.16.1
tagger Myles Borins <mylesborins@google.com> 1582054399 -0500

2020-02-18 Node.js v12.16.1 'Erbium' (LTS) Release
Git-EVTag-v0-SHA512: ea563ab5c70725724035e1adc8f2e1552c5f4e90d44345ebdc50360d6f24d2c9c77945bf37c946ace3b1374a903bdc3660ea35b6842ec5d8431a7374d54808ac
gpg: Signature made Tue Feb 18 14:33:19 2020 EST
gpg:                using RSA key 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Good signature from "Myles Borins <myles.borins@gmail.com>" [unknown]
gpg:                 aka "Myles Borins <mylesborins@google.com>" [unknown]
gpg:                 aka "Myles Borins <mborins@google.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C4F0 DFFF 4E8C 1A82 3640  9D08 E73B C641 CC11 F4C8
     Subkey fingerprint: 0EFF E1BC EFD9 C84E 3D09  8152 933B 01F4 0B5C A946

This is no different than a signature I did almost a year ago on the 8.x release line

object 5f93cf7e3a732b0ace1ccc9950d88cdb5d6ff029
type commit
tag v8.16.0
tagger Myles Borins <mylesborins@google.com> 1555433090 -0400

2019-04-16 Node.js v8.16.0 'Carbon' (LTS) Release
Git-EVTag-v0-SHA512: 18251dcf7c4359932dd727cd0ed4b2c27566cf1aecb9ba92c65d697483bdf028170e00c60f17f85563d305405b30fa504a2581325629f6a2386f76f233f5eacf
gpg: Signature made Tue Apr 16 12:44:50 2019 EDT
gpg:                using RSA key 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Good signature from "Myles Borins <myles.borins@gmail.com>" [unknown]
gpg:                 aka "Myles Borins <mylesborins@google.com>" [unknown]
gpg:                 aka "Myles Borins <mborins@google.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C4F0 DFFF 4E8C 1A82 3640  9D08 E73B C641 CC11 F4C8
     Subkey fingerprint: 0EFF E1BC EFD9 C84E 3D09  8152 933B 01F4 0B5C A946

How are you validating the signature and what error are you seeing?

[MylesBorins]

I don't believe this change should land, it is identifying my subkey not primary key

[MylesBorins]

Wanted to also show that on the keyserver the shortkey for both of these return the exact same primary key and show the same fingerprint (that we include in the readme)

http://pool.sks-keyservers.net/pks/lookup?search=0xCC11F4C8
http://pool.sks-keyservers.net/pks/lookup?search=0x0B5CA946&fingerprint=on&op=index

[haqer1]

How are you validating the signature and what error are you seeing?

The command used (as suggested in https://github.com/nodejs/node#verifying-binaries) & the error that a user not having any of these 2 keys (i.e., all new users, etc.) gets is (similar to what's on the bottom of the original issue post (#32559 (comment))):

$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: Signature made ...
gpg:                using RSA key 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Can't check signature: No public key

And as i've mentioned on the issue, that's confusing because 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946 key is not listed on the README. Thus a security-concious dude(tte) would be required to spend time on figuring out what's going on. Obviously, that's not how it should be.

P.S. This error can be reproduced after importing the relevant key by running (for instance):
gpg --delete-keys 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
P.P.S. It goes away after running (for instance):
gpg --keyserver pool.sks-keyservers.net --recv-keys 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
Therefore, 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946 key should be listed on the README(.md) to make it easier (& less confusing or scary) for the users.

[haqer1]

This is no different than a signature I did almost a year ago on the 8.x release line

I've spent a few more minutes, & in fact the same situation applies to 8.16.0 & 13.12.0, which is an argument in favor of merging this PR rather than #32565:

.../nodejs/8.16.0$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: Signature made <date/>
gpg: using RSA key 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Can't check signature: No public key

.../nodejs/13.12.0$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: Signature made <date/>
gpg: using RSA key 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Can't check signature: No public key

[MylesBorins]

LGTM

Not approving, not objecting

[MylesBorins]

I'll be honest that I'm still not 100% convinced that this is the right thing to do. Pulling my primary key from the keyserver includes the subkey that the releases are signed with, and the subkey has the signature of the primary key which is currently documented. This has worked for 4 years without issue, and even allowed me to move between subkeys that I used to signed without having to update the documentation.

Is there someone from the project with more gpg experience who can chime in on what the appropriate thing to do here would be? I don't want to block, but am not going to approve this either without a bit more research.

[haqer1]

IMHO: World is confusing enough, & time is a valuable resource. If confusions can be avoided, & time can be economized, it should be done.

[MylesBorins]

@jasnell you seem to also have a primary key in the README but use a separate subkey for signing... thoughts on this?

[jasnell]

I think I'm -1 on this change. The instructions are clear that the first necessary step is to import the releaser keys (https://github.com/nodejs/node#release-keys) and once that is done the signature verifies correctly without importing the subkey directly.

[MylesBorins]

Landed #32591 instead