Release PGP key strategy and policy

[rvagg]

Continuation of #681 but specifically on the topic of PGP keys for signing releases.

Context: release builds come from a git tag of the form vx.y.z which is signed by an authorized releaser (see git tag -v v1.0.4 or any other release tag) with their personal PGP key. Release builds available on iojs.org have a have a SHASUMS256.txt file generated for all downloadable assets (minus the docs/ directory). This file is also signed with the same key that signed the git tag for that release and the signed file is made available as SHASUMS256.txt.asc. An ASCII armoured version of their public key is also made available as SHASUMS256.txt.gpg for convenience.

The procedure I put in place in #681 for releases says that:

• releasers should list their full key fingerprint on the README (mine is there now); and
• the keys should also be submitted to https://sks-keyservers.net/ - the README also now contains instructions for how you can verify a download which includes this keyserver. See #verifying-binaries

Questions for discussion:

@bnoordhuis asked if we could

use a single master key with as many sub-keys as there are release managers? It would make all releases be signed by "io.js Release Engineering releng@iojs.org" (or whatever we decide to call ourselves) and it makes revocation a little easier. Master key management is an open issue, though; who gets to own it?"

My response is that I don't feel strongly about this but:

My personal bias is towards decentralising this and making individuals responsible for signing their releases with their own keys, simply because I think decentralisation in most aspects of the project are more healthy for the community focus and ethos that we're trying to foster. It also makes that individual properly responsible for that release rather than it just being a mechanical task.

@chrisdickinson had trouble submitting to sks-keyservers.net and @indutny suggested https://pgp.mit.edu/ might be a better alternative

My response is:

The only reason I chose sks-keyservers.net was because the only precedent I'm aware of for checking signed shasums is in the Docker images for both Node (official Docker ones) and io.js and that's what they've chosen to use. I don't know the reasoning behind this but I went with that as an established convention.

Both of these points need discussion, I'm labelling this as tc-agenda but please don't take that as a sign that this is only for the TC to discuss. Opinions welcome from those with expertise on this matter.

[indutny]

I have a proposal. We need a rogue server without ssh access and encrypted file system. The server will be placed on the moving truck and will carry the private key on the hard drive. Only if the majority of current TC will sign the message - it'll generate the revocation request.

[rvagg]

@indutny only a single server and truck carrying the entire key? surely you jest! we must split that key up across at least two separate trucks, driven by individuals of different nationalities.

[rvagg]

from this: https://sks-keyservers.net/status/ it looks like pgp.mit.edu is in the sks-keyservers.net pool

[pesho]

The sks-keyservers pool has a web interface for submitting keys, it should be painless: https://sks-keyservers.net/i/#submit (sorry, didn't see this was already mentioned)

There is a delay of ~30 min after submission before the key propagates to all the servers in the pool. I think that's worth putting up with - a pool of servers should be more reliable than a centralized service.

[canterberry]

I know this is ancient history, but it seems the most appropriate place to report the issue.

SKS key servers is a dead project and it is not (and has not been) a reliable mechanism for handling PGP keys for some time, and recently suffered a devastating attack that all but destroyed the network.

Instead, a simple solution to distributing the verified release keys for authorized members of the release team would be to publish them to nodejs.org directly and/or to this repo (e.g: to a keys subdirectory).

[rvagg]

There's also a new keyserver maintained by OpenPGP: https://keys.openpgp.org/about/news#2019-06-12-launch (some notes in there about SKS).

Not a bad idea putting the keys directly into the repo, and you're probably right that we should migrate our instructions. I don't suppose you'd be up for starting a pull request to make this happen @canterberry? doc/releasekeys/ might be a good place to put them.