Skip to content

Clarify which people should be org owners #125

Description

@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?

Activity

  1. jasnell commented on Aug 4, 2016

    @jasnell
    Member

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

  2. mikeal commented on Aug 4, 2016

    @mikeal
    Contributor

    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 :)

  3. jasnell commented on Aug 4, 2016

    @jasnell
    Member

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

    Why not?

  4. mikeal commented on Aug 4, 2016

    @mikeal
    Contributor

    @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.
  5. jasnell commented on Aug 4, 2016

    @jasnell
    Member

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

  6. mikeal commented on Aug 4, 2016

    @mikeal
    Contributor

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

  7. mikeal commented on Aug 4, 2016

    @mikeal
    Contributor

    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.

  8. jasnell commented on Aug 4, 2016

    @jasnell
    Member

    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.

  9. mikeal commented on Aug 4, 2016

    @mikeal
    Contributor

    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.

  10. nebrius commented on Aug 10, 2016

    @nebrius
    Contributor

    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).

  11. Starefossen commented on Aug 11, 2016

    @Starefossen
    Member

    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.

  12. mhdawson commented on Oct 20, 2016

    @mhdawson
    Member

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

  13. ChALkeR commented on Mar 3, 2017

    @ChALkeR
    Member

    @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.

  14. mikeal commented on Mar 4, 2017

    @mikeal
    Contributor

    @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.

  15. williamkapke commented on Mar 24, 2017

    @williamkapke
    Contributor

    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.

  16. mikeal commented on Mar 24, 2017

    @mikeal
    Contributor

    @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?

  17. williamkapke commented on Mar 24, 2017

    @williamkapke
    Contributor

    @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

  18. bnoordhuis commented on Mar 26, 2017

    @bnoordhuis
    Member

    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.)

  19. nebrius commented on Mar 27, 2017

    @nebrius
    Contributor

    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.

  20. mikeal commented on Mar 28, 2017

    @mikeal
    Contributor

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

  21. phillipj commented on Mar 28, 2017

    @phillipj
    Member

    @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.

  22. mhdawson commented on Apr 3, 2017

    @mhdawson
    Member

    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 ?

  23. jbergstroem commented on Apr 3, 2017

    @jbergstroem
    Member

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

  24. williamkapke commented on Apr 9, 2017

    @williamkapke
    Contributor

    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/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions