Repository navigation
New strategy for managing, sharing and documenting release keys needed #1913
Description
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)
Activity
MylesBorins commentedon Sep 12, 2019
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 commentedon Sep 12, 2019
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 commentedon Sep 12, 2019
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 commentedon Sep 12, 2019
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 commentedon Sep 12, 2019
A dedicated nodejs/keys repo makes sense to me.
canterberry commentedon Sep 12, 2019
If a nodejs maintainer creates the repo, I'll create a PR to pull in the keys.
canterberry commentedon Sep 12, 2019
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:
GNUPGHOME=in scripts that need a keyring for verification.I'm putting together a revised script to import all release signing keys now.
sam-github commentedon Sep 12, 2019
@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 commentedon Sep 12, 2019
@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 commentedon Sep 13, 2019
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 commentedon Sep 13, 2019
@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 commentedon Sep 13, 2019
richardlau commentedon Oct 31, 2019
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.richardlau commentedon Nov 5, 2019
ping @nodejs/tsc
mcollina commentedon Nov 9, 2019
I'm +1 on the approach @canterberry is proposing.
mhdawson commentedon Nov 20, 2019
Discussed in TSC meeting. @BethGriggs will add to agenda for Release WG and come back with a recommendation.
sam-github commentedon Nov 20, 2019
I'm fine with the canterberry approach, the Release WG's recommendation is fine by me.
BethGriggs commentedon Dec 5, 2019
We discussed this in the release meeting today - we were all +1 on the dedicated "nodejs-keys" repository approach.
sam-github commentedon Dec 27, 2019
Should
build-agendabe 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 commentedon Dec 28, 2019
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 commentedon Dec 29, 2019
nodejs/admin#456 has been opened.
github-actions commentedon Oct 24, 2020
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.