-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transfer canterberry/nodejs-keys into nodejs/keys #456
Comments
@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. |
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. |
|
+1 as long as build and TSC +1. I'm also okay with One thing I would recommend is avoiding duplicate information, like the org name ❤️ |
Remember we already have a repo that contains 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 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 +1 to distinguishing in READMEs. The description could also include something along the lines of |
@joyeecheung 👍 Knowing now that both
|
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). |
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 |
+1 to what @targos said - there is no |
Node.js STILL has not sorted this out and keeps list of keys in the README... nodejs/admin#456
Spotted this little issue here while looking for the |
@nodejs/build Any reason not to go ahead and do this at this point? |
@Trott reading through I'd say as long as
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 |
I'd like to assert again that redundancy in naming repos with the prefix I do feel strongly about this, but won't block on it. |
@bnb my bad the current proposal is nodejs/keys will update above. |
I have a slight preference for |
Like @targos I prefer nodejs/release-keys as well, but don't feel too strongly about it. |
I also prefer |
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.
👍. 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.
The release team has discussed this at least twice in previous WG meetings (most recently in May) and are in favour of proceeding.
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 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 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:
I'll get started on option 3. |
|
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. |
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
.The text was updated successfully, but these errors were encountered: