Clarify which people should be org owners

[addaleax]

On today’s TSC meeting it was noticed that, while I was made an owner of the nodejs org as part of my addition to the CTC, but e.g. @nebrius and @mhdawson were not as part of joining the TSC/CTC respectively. There should probably be a clear rule for this?

[jasnell]

+1 ... I'd been under the impression that all CTC / TSC members should be org owners (and still feel that way).

[mikeal]

So, there isn't a 1-to-1 relationship because we don't want every TSC/CTC member to be a security group member, and they are a defacto member if they are an org owner.

I hope that we can eventually remove almost everyone as org owners once the bot does all the things you need to be an org owner to do :)

[jasnell]

we don't want every TSC/CTC member to be a security group member?

Why not?

[mikeal]

@jasnell a few reasons:

• The TSC should eventually include people from other sub-projects like libuv.
• The TSC should eventually include people from non-technical groups: evangelism. (Inclusivity is already in the TSC for example).
• The security group shouldn't be huge. One of the things we heard from CII was that having an incredibly large security group can deter some people from reporting vulnerabilities.

[jasnell]

Ok, then perhaps make it: all CTC members should have org ownership?

[mikeal]

@jasnell is there a reason that the security group should be the entire CTC rather than a subset?

[mikeal]

BTW, one reason I'm a little freaked out about this is because the NodeSchool org was very liberal about adding org owners and at some point one of them accidentally deleted the org. GitHub was able to restore it but there were problems with getting all the watches back and a lot of other dangling issues that were pretty annoying.

[jasnell]

The various security related changes we've had to make tend to be rather significant. The various points of view on the CTC ought to have visibility into those issues and related discussions.

[mikeal]

In fact, the reason the initial work on the bot happened in nodeschool, which we are now building on, was to work around adding so many people as org owners.

[nebrius]

For the record, I'm fine not being an org owner if the bot can do all the things I would need permission to do that I don't normally have. I kinda like the idea of limiting the number of owners is a good one, given how many permissions are given that aren't needed for day to day work (and even occasional work).

[Starefossen]

one of them accidentally deleted the org

I bet it would be possible to ask GitHub support to disable this "feature" for the Node.js org.

[mhdawson]

Late to the party but I'm already in the security group so adding me should not be an issue.

[ChALkeR]

@mikeal

is there a reason that the security group should be the entire CTC rather than a subset?

I think that the CTC should have access to all issues in the security repo, as security-related issues sometimes play an important role for providing background for technical decisions.

That doesn't mean that the whole CTC should be explicitly added to the security group, or to the security@ email (which it isn't now afaik).

To clarify: I am not stating that CTC should or should not be the org owners in this comment, but this specific argument (access to the security repo) against adding all the CTC to owners doesn't seem important to me.

[mikeal]

@ChALkeR ya, not that worried about the security group, much more worried about the secrets repo.

This isn't about trying to hide information from people, it's about increasing the surface area that our infrastructure can be compromised by. Very nasty things could happen to Node.js if people were to compromise the infrastructure without us knowing. Giving people access to the keys to that infrastructure when they don't even want or need them just isn't a good idea.

Also, I think this discussion has gotten a little farther along in a different PR in this repo somewhere.

[williamkapke]

It has been mentioned to me (by a few people independently) that this would be solved by moving the secrets repo out of the org and controlling access to it in the new location.

Whatever the solution, it is overdue and that surface area is increasing. @nodejs/TSC please take the steps to resolve this.

[mikeal]

@williamkapke I noticed that your bot is up and running and solving most of the issues that have driven a need to expand the owners list. Is that an accurate statement?

[williamkapke]

@mikeal No- probably a long way to go before that becomes a reality. There was pushback when I offered it. See: nodejs/community-committee#22

I don't claim for it to be the PERFECT solution that everyone will love either- I feel it is in the 'critique' stage at best.

It would still need:

• to get approved
• to get setup on Foundation hardware
• permissions granted to a special bot account
• repo webhooks pointed to it and READMEs updated with the special comment in it (to manage the members)

The bot is here: https://github.com/williamkapke/orgbot

[bnoordhuis]

I'm okay with moving out the secrets repo if the logistics can be worked out. Who would be responsible for it after the move?

(Feel free to move this discussion into a new issue if it should be one.)

[nebrius]

Echoing what @bnoordhuis said, I'm also ok with moving the secrets repo out, but I also think we should figure out what that org (if it even is an org) looks like and who owns it before we move it. I think we should keep ownership the same, meaning that all CTC members would be added as owners in the new org (if I understand the current ownership correctly).

I think it could also be useful to move the security repo out as well. Even though it's not as much of a pain point (as mikeal mentioned), it's still been brought up in conversations before around adding people as owners.

[mikeal]

I'd like @nodejs/build to weigh in since it's their repository :)

[phillipj]

@mikeal said:
Giving people access to the keys to that infrastructure when they don't even want or need them just isn't a good idea.

The keys in there aren't readable to you unless your GPG key has been added. Without that in place, one might get some hints about providers we use by looking at the key filenames, but that's no secret: build/README.md.

[mhdawson]

When we say moving out what would that mean, we'd move it out to another organization like nodejs-xxx and then the repos would be managed there ?

[jbergstroem]

I don't see the need to move it out either. We rely on gpg for access management, not github acl.

[williamkapke]

In the meeting (#237) there was a desire for a list of GitHub permissions.

Here you go:
https://help.github.com/articles/permission-levels-for-an-organization/