New strategy for managing, sharing and documenting release keys needed

[rvagg]

Arising from @canterberry's comments @ nodejs/node#709 (comment)

I haven't really paid too much attention to the SKS issues except that OpenPGP mentioned it the other day, but it seems like we need a new strategy for distributing our release keys for verifying signatures and therefore shasums of downloads.

This is a tracking issue that we could use for discussion and just to make sure it doesn't get fully lost. Someone needs to take the horns of this bull and come up with a strategy, even if that's just putting the keys into the nodejs/node codebase and recommending them from there, or getting all releasers keys onto the new OpenPGP server. Docs will need to change too.

@nodejs/build @nodejs/releasers @nodejs/tsc (FYI)

[MylesBorins]

I'm a big +1 on documenting releasers + keys in the repo. We already do so in the readme. We could make adding / removing the keys part of the process of adding / removing releasers.

[rvagg]

I'm a little concerned about them going into nodejs/node given the very large collaborator group and the pace of change which means that very few people (if anyone?) see everything that goes in. An alternative might be dedicated nodejs/keys that's got very restricted write access, TSC-only probably.

[canterberry]

There is already a nodejs/Release repo. This repo is pretty sparse and updated relatively infrequently. Would that be a reasonable place to keep the keys of the authorized release team? I know I find myself checking there first whenever I want to see who the authorized releasers are.

I second the notion of a dedicated repo, too, with restricted access.

[rvagg]

might work but I think it has at least 2 additional teams that have access, Releasers (which is fine, it's their keys anyway), and LTS, or maybe it's called Release now (the repo used to be called LTS). That's still a broad group that could be pared back; but maybe it's time to revisit the purpose of that repo and who runs it.

[mhdawson]

A dedicated nodejs/keys repo makes sense to me.

[canterberry]

If a nodejs maintainer creates the repo, I'll create a PR to pull in the keys.

[canterberry]

I created a prototype repo for review here: https://github.com/canterberry/nodejs-keys
This repo contains a few different patterns that don't all necessarily need to exist, but are included for completeness:

• A keys.list that contains just a newline-delimited list of signing key IDs.
• A GPG keyring preloaded with all release signing keys, for use with GNUPGHOME= in scripts that need a keyring for verification.
• A keys/ directory with ASCII-armor outputs of each release signing key, named according to the key ID.
• A README initialized (verbatim) from the Release Keys section of the nodejs/node repo's README.

I'm putting together a revised script to import all release signing keys now.

Edit: The repo now incudes a CLI for managing Node.js release signing keys, and the README now includes instructions on how to import these keys and/or use the preloaded GPG keychain.

[sam-github]

@canterberry @rvagg We recently had difficulty talking to Mitre because they wanted to gpg email info to the node.js project. Sorry if this is a tangent, but I wonder if a security contact public key could go in there, too? The private part could go in nodejs-private/secrets. Or, perhaps releasers or TSC members GPG pub keys should be in there, and the sec page can say "contact any TSC member"?

I'm not sure how well gpg identities work for an organizational role, the seem more tied to an individual, and if there was a gpg identity for node.js security, it raises the issue of revocation -- if someone leaves the sec or tsc teams, how can their access to the secrets be revoked? Is this something we deal with in nodejs/build? I know that once my key is removed from the build secrets, I won't be able to decrypt them anymore, but I think if I have decrypted versions sitting on my laptop, I remain in possession. Do we care? Is there any way to deal with this?

[canterberry]

@sam-github I don't think it's too much of a tangent at all. If there are other teams apart from the release team (e.g: security) that need a repository to publish their keys, then such a repo could serve those keys as well, at least until keys.openpgp.org matures and/or there are more reliable public keyservers available.

Secrets management is a complex subject that I do think probably extends beyond the scope of this particular thread. I'd be happy to continue that discussion in a separate thread, @sam-github.

[rvagg]

Nice work @canterberry, I'm +1 on just pulling that over into the org. I added an issue about auditing needed post move just as a reminder.

@sam-github I think that repo could serve the same purpose, and yes, into nodejs-private/secrets with the private. We'd have to figure out who gets access to that though, probably not in the current "test", "release" and "infra" categories we have now, something new probably.

There have also been suggestions in the past to delegate from an "official" key to the releasers keys to establish the trust so that could be explored too if we go that way. I'm not super keen on one-key-to-rule-them-all but having an org like Mitre want to connect to another org does make it difficult when we don't have the same type of organisational hierarchy that they anticipate. I'm +1 if you want to go ahead and make that happen. @bnoordhuis has opinions here too IIRC.

[rvagg]

@sam-github @mhdawson @MylesBorins over to you re adopting https://github.com/canterberry/nodejs-keys, maybe take it to a TSC meeting to get agreement on the approach?

[MylesBorins]

Taking to TSC seems reasonable to me

…

On Thu, Sep 12, 2019, 8:52 PM Rod Vagg ***@***.***> wrote: @sam-github <https://github.com/sam-github> @mhdawson <https://github.com/mhdawson> @MylesBorins <https://github.com/MylesBorins> over to you re adopting https://github.com/canterberry/nodejs-keys, maybe take it to a TSC meeting to get agreement on the approach? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1913?email_source=notifications&email_token=AADZYV4NGXJRAVWJOLB3JPLQJLP3ZA5CNFSM4IV22J5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TVIFI#issuecomment-531059733>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADZYV2UTPJJ25QEG364QWDQJLP3ZANCNFSM4IV22J5A> .

[richardlau]

This appears to have stalled? The last comments suggest taking to @nodejs/tsc but that doesn't appear to have happened (unless there were private discussions).

I'll tag tsc-agendatsc-review -- Maybe this falls under the repsonsibilities delegated to the Release WG? @nodejs/tsc This issue relates to nodejs/node#29531 and relates to the current method of distributing the @nodejs/releasers keys used to sign releases via the SKS keyserver network being no longer being viable. The proposed solution is to publish the keys somewhere under our control.

• Release signing keys may be poisoned node#29531 proposes adding them to the core repository, https://github.com/nodejs/node/.
• New strategy for managing, sharing and documenting release keys needed #1913 (comment) proposes adding them to https://github.com/nodejs/Release.
• The recommendation in this issue appears to have coalesced around transferring the work done by @canterberry in https://github.com/canterberry/nodejs-keys into the organization with appropriate restrictions on write access.

[richardlau]

ping @nodejs/tsc

[mcollina]

I'm +1 on the approach @canterberry is proposing.

[mhdawson]

Discussed in TSC meeting. @BethGriggs will add to agenda for Release WG and come back with a recommendation.

[sam-github]

I'm fine with the canterberry approach, the Release WG's recommendation is fine by me.

[BethGriggs]

We discussed this in the release meeting today - we were all +1 on the dedicated "nodejs-keys" repository approach.

[sam-github]

Should build-agenda be removed? The discussions all seemed to point towards an agreed approach, now it just has to be taken up by someone.

It doesn't look like anything needs to be resolved.

[sam-github]

And if the ask is to move https://github.com/canterberry/nodejs-keys into the nodejs/ org, follow the procedure described in https://github.com/nodejs/admin/blob/master/GITHUB_ORG_MANGEMENT_POLICY.md#repositories

@canterberry Open an issue as described in above link, reference this, it should get approved pretty quickly.

[richardlau]

nodejs/admin#456 has been opened.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.