Transfer canterberry/nodejs-keys into nodejs/keys

Delivers nodejs/build#1913.

Summary

https://github.com/canterberry/nodejs-keys → https://github.com/nodejs/keys

The proposed nodejs/keys repo would hold the PGP signing keys for members of the Node.js release team.

Permissions

This repo should be readable by the general public, but only members of the Node.js organization with permission to manage membership in the release team should have write or merge privileges on master.

@nodejs/build @nodejs/tsc

@nodejs/community-committee

👍

Only suggestion I’d have to is to be more explicit when naming the repo, e.g. nodejs/release-keys rather than just nodejs/keys.

@addaleax

Well observed, @addaleax. In the immediate term, the only known use case for this repo would be for the release team's signing keys. However, there's little reason why it could not be the source of truth for the PGP keys of other members of the organization as well! For example, members of the security team, for researchers to submit vulnerability disclosures via encrypted email.

^ I agree, I was imagining the same thing re adding the option of sending encrypted emails to security@, report@, etc.

nodejs/pgp-keys? nodejs/org-keys? nodejs/nodejs-keys?

+1 as long as build and TSC +1. I'm also okay with nodejs/keys simply based on my personal naming aesthetics, but can understand why others may differ. If we plan on including additional keys, I think this makes even more sense given that it'll be a generic catch-all and we can avoid forcing a specific use with the most generic term.

One thing I would recommend is avoiding duplicate information, like the org name ❤️

Remember we already have a repo that contains keys:

github.com/nodejs/keys - has gpg keys
github.com/nodejs/secrets - has ssh keys

I don't think anybody could guess that from the names.

Thus my suggested more specific names: #456 (comment)

Not blocking, just anticipating people coming along and wanting to know why the build keys aren't in "nodejs/keys".

@sam-github

@sam-github https://github.com/nodejs/secrets contains private keys (for ssh-ing into the machines), https://github.com/nodejs/keys doesn't seem to exist? (EDIT: oh right, its what this issue requests) From what I can tell, https://github.com/canterberry/nodejs-keys only contains public keys. I guess we should be fine if simply document what those repos are in the README, or the distinction would be obvious from the fact that https://github.com/nodejs/secrets is um, private

@joyeecheung

@joyeecheung +1 to distinguishing in READMEs. The description could also include something along the lines of If you're looking for public keys, please see [nodejs/keys](). and If you're looking for private keys, please see [nodejs/secrets (private)](). for nodejs/secrets and nodejs/keys, respectively.

@joyeecheung

@joyeecheung 👍 Knowing now that both nodejs/keys and nodejs/secrets both currently exist and contain secrets, to revise my initial proposal:

Move all GPG private keys into the nodejs/secrets repo.
Delete the current private nodejs/keys repo (to ensure private keys are absent from the repo history).
Create a new nodejs/keys repo, initially marked as private.
Copy the contents of canterberry/nodejs-keys into the nodejs/keys repo.
Perform an internal review/audit of the nodejs/keys repo at this point to ensure its accuracy and trustworthiness.
Mark the nodejs/keys repo as public.
Update references to Node.js release signing keys to direct users to the nodejs/keys repo as the source of truth for these.
Incorporate addition/removal of signing keys into the onboarding/offboarding process for authorized members of the release team.

What is this existing nodejs/keys repo? Can someone with org access please definitively confirm that such a thing exists and what it contains? I'm not aware of it ever existing and have only been without org admin access for a year or so now. The secrets repo is nodejs-private/secrets. I don't believe we're storing GPG private keys for anything anywhere, I know for sure we're not in secrets. Our policy to date has for people who access nodejs-private/secrets (and releasers who sign releases) to maintain their own GPG keys and we just use public keys for encrypting shared secrets so they can be accessed by certain individuals only (see https://github.com/ConradIrwin/dotgpg for our main tool).

@rvagg

Thanks for clarifying @rvagg . It's a bit unclear to non-members whether such a repo exists, since if it does it would be private. It wasn't until this comment that it seemed like there might be a conflict preventing this proposal from moving forward.

There is no nodejs/keys repository

@targos

+1 to what @targos said - there is no nodejs/keys repo (confirming as an org owner).

@Trott

@Trott reading through I'd say as long as

We have agreement on using nodejs/keys versus something else like nodejs/release-keys.
In terms of managing the content, its limited as outline in the original post
There is enough buy in from the Release team

We should be ready to move ahead.

I'm not sure on 1) and 3) though from the discussion comments in the thread. In particular 3) is
the one I'm most unsure on from the people who have commented in the issue. @BethGriggs what's your take on that?

I'd like to assert again that redundancy in naming repos with the prefix nodejs is confusing and inconsistent (nodejs/next-10 rather than nodejs/nodejs-next10 is a recent example). It would be ideal to strive for consistency across the org rather than having one-offs that use this prefix. As far as I can tell, as an org owner, keys does not exist in the nodejs org.

I do feel strongly about this, but won't block on it.

@bnb

@bnb my bad the current proposal is nodejs/keys will update above.

I have a slight preference for nodejs/release-keys over nodejs/keys

@targos

Like @targos I prefer nodejs/release-keys as well, but don't feel too strongly about it.

I also prefer nodejs/release-keys. I don't think it makes sense to mix release keys (which are more consumer-facing) with other keys used throughout the project for maintenance, so would prefer the more explicit naming.

We have agreement on using nodejs/keys versus something else like nodejs/release-keys.

There's been preferences stated for (including from the release team, https://github.com/nodejs/Release/blob/main/doc/meetings/2021-05-20.md), and no objections to, nodejs/release-keys.

In terms of managing the content, its limited as outline in the original post

👍. I think there was some confusion earlier in the thread with how we store secrets for the Build team, but this proposal is specifically for the keys used to sign releases.

There is enough buy in from the Release team

The release team has discussed this at least twice in previous WG meetings (most recently in May) and are in favour of proceeding.

We should be ready to move ahead.

So what needs to happen next by whom? Does the transfer need to be done by an org owner?

The sks-keyservers that the release keys were being uploaded to no longer work (nodejs/docker-node#1500, nodejs/node#39114). In the short term we could pick an alternative keyserver but I think the proposal here and having the keys somewhere under our control would be the way forward.

If there are no objections I can go ahead and transfer the repository to https://github.com/nodejs/release-keys. We can then look at updating our related documentation/guidance on verifying, onboarding, etc.

I'm happy to help with anything needed of me for the transition or subsequent maintenance.

@canterberry

@canterberry would you mind adding me as an admin to your repository so I can initiate the transfer? (I'm assuming I need to have admin/create repository permissions in both places to do so.)

@BethGriggs

@BethGriggs Since the repo is under my personal GitHub user, it doesn't look like I can grant permissions for you to initiate a transfer of the repo. For visibility and review by current and future parties of interest, we have a few options:

If I were granted temporary access to create public repos in the nodejs org, I can transfer the repo, then the permission can be revoked. This would carry some risk of me potentially creating rogue repos, but that could easily be detected and remedied.
You could fork canterberry/nodejs-keys into the nodejs org, then would be able to manage access to that fork. That would carry forward the original attribution to my repo in a highly visible way, though, and it would be treated by GitHub as a fork rather than a source repo.
I could transfer canterberry/nodejs-keys into an org under my control, invite you to that org, create a team to administer that repo, add you to that team, grant permission for that team to administer the repo, then you transfer the repo to the nodejs org. While it's a convoluted path, it would (in theory) properly migrate the repo along with its related issues, PRs, history, and attribution. Then, I'd create a fork of nodejs/release-keys into canterberry/nodejs-keys to mitigate breaking any current dependencies.

I'll get started on option 3.

@BethGriggs

Transferred canterberry/nodejs-keys to twuni/nodejs-keys.
Invited Beth to a team in that org with administrative access to the nodejs-keys repo.
Forked twuni/nodejs-keys to canterberry/nodejs-keys for continuity.
@BethGriggs to transfer twuni/nodejs-keys to nodejs/release-keys.
@canterberry to ensure canterberry/nodejs-keys fork is properly tracking nodejs/release-keys
@canterberry to add migration notice to canterberry/nodejs-keys

@canterberry

Thanks @canterberry, https://github.com/nodejs/release-keys now exists. I'll remove myself from the org too.

Now that the transfer itself is complete, closing this issue.

Navigation Menu

Repository navigation

Transfer canterberry/nodejs-keys into nodejs/keys #456

Summary

Permissions

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Transfer canterberry/nodejs-keys into nodejs/keys #456

Description

Summary

Permissions

Activity

Trott commented on Dec 28, 2019

Trott commented on Dec 28, 2019

addaleax commented on Dec 28, 2019

canterberry commented on Dec 29, 2019

rvagg commented on Dec 30, 2019

sam-github commented on Dec 30, 2019

bnb commented on Apr 23, 2020

sam-github commented on Apr 23, 2020

joyeecheung commented on Apr 24, 2020

bnb commented on Apr 27, 2020

canterberry commented on May 15, 2020

rvagg commented on May 16, 2020

canterberry commented on May 16, 2020

targos commented on May 16, 2020

bnb commented on May 16, 2020

3 remaining items

mhdawson commented on May 18, 2021

bnb commented on May 18, 2021

mhdawson commented on May 18, 2021

targos commented on May 19, 2021

mhdawson commented on May 19, 2021

BethGriggs commented on May 20, 2021

richardlau commented on Jun 22, 2021

BethGriggs commented on Jun 23, 2021

canterberry commented on Jun 24, 2021

BethGriggs commented on Jun 24, 2021

canterberry commented on Jun 24, 2021

canterberry commented on Jun 24, 2021

BethGriggs commented on Jun 24, 2021

canterberry commented on Jun 24, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions