Skip to content
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

github: consider downscoping "GitHub Editors" access to Triage role #39055

Open
dmitshur opened this issue May 13, 2020 · 10 comments
Open

github: consider downscoping "GitHub Editors" access to Triage role #39055

dmitshur opened this issue May 13, 2020 · 10 comments

Comments

@dmitshur
Copy link
Member

@dmitshur dmitshur commented May 13, 2020

The Go project offers access to a set of people to edit metadata on GitHub issues, in order to help with gardening. This access is documented at https://golang.org/wiki/GithubAccess#editors.

Back when the "go-approvers" group was created, GitHub did not offer granular access levels, it was either Read (no access to triage), Write (access to triage and push), Admin. We used Write since it was the most fitting option.

The GitHub repository at https://github.com/golang/go is a mirror of the canonical repository at https://go.googlesource.com/go where code review happens, and any changes to it are automatically overwritten by gitmirror. However, accidents happen occasionally, and people may unintentionally create new branches (e.g., see https://groups.google.com/d/msg/golang-dev/EqqZf5kTRqI/9BEDmjHwBwAJ).

By now, GitHub seems to offer more granularity in access controls, including a "Triage" role:

image

It's documented in more details at https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization.

We should investigate and confirm whether it's safe to downscope the go-approvers team to Triage access without causing unintended inconvenience to people who rely on it, and if so, apply the change.

/cc @golang/osp-team @katiehockman @FiloSottile

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented May 13, 2020

Oh nice, strong support for this. I think Write also allows doing things like creating releases, which can easily lead to very effective social engineering attacks.

@mvdan
Copy link
Member

@mvdan mvdan commented May 15, 2020

Yes please. I can't think of anything else github access should be granting. Perhaps moderating the wiki? Though I think that's mostly done by the Go team anyway.

@dmitshur
Copy link
Member Author

@dmitshur dmitshur commented Sep 16, 2020

Given that we recently went through a change on Gerrit side for #40699 (/cc @rsc @andybons), I wanted to revisit this now. This issue has received favorable feedback so far.

We should investigate and confirm whether it's safe to downscope the go-approvers team to Triage access without causing unintended inconvenience to people who rely on it, and if so, apply the change.

To investigate this, I read GitHub documentation further (it contains very detailed information). The Triage access level is described as "Recommended for contributors who need to proactively manage issues and pull requests without write access", which seems like a good fit for our intent for the "go-approvers" group, described as "the set of people who can edit metadata on issues."

According to the detailed access table, Triage level adds these permissions compared to Read level:

  • Apply labels
  • Close, reopen, and assign all issues
  • Apply milestones
  • Mark duplicate issues and pull requests

That should work well for most needs that come up during gardening.

However, there are some permissions granted only in the Write access level which are sometimes helpful or necessary, for example:

  • Edit and delete anyone's comments on commits, pull requests, and issues
  • Hide anyone's comments
  • Lock conversations
  • Transfer issues

We definitely need some people to be able to perform those actions. As far as I can tell, we have golang organization admin groups that will continue to have these permissions, and that may be sufficient. (Unfortunately, this means some people will still be able to accidentally create branches on GitHub, etc., but at least that set of people will be greatly reduced.)

I think a good next step here is to apply this change and communicate that to golang-dev@, asking for feedback if it turns out to be problematic or more-harmful-than-helpful. Based on the feedback we hear, we may need to adjust groups and permissions further. But it's seems hard to learn more unless we actually try it.

If all that still sounds good and there aren't new concerns, I'll plan to do that next week or so.

@dmitshur dmitshur self-assigned this Sep 16, 2020
@ALTree
Copy link
Member

@ALTree ALTree commented Sep 17, 2020

I wouldn't be too happy if this is implemented.

I use all of these:

  • Edit and delete anyone's comments on [...] issues
  • Hide anyone's comments
  • Lock conversations
  • Transfer issues

more or less regularly.

  • Transferring issues is useful when an issue meant for the tools or
    tour trackers is opened here.
  • I hide comments to keep threads tidy when, in the early stages of
    triaging, people -including me- post comments that are subsequently
    made outdated or uninteresting by a clarification from the OP; I
    also hide comments that are not on-topic but not so ill-mannered
    as to require deletion. I delete out-of-topic vulgar comments, and
    spam.
  • Locking threads can be useful to prevent people from having
    conversations on a closed issue, and as a stronger form of 'close',
    to signal that no further reply is welcome, usually on issues
    that get closed for being obviously trollish.
  • I regularly edit issues with messed up formatting, opened by people
    who don't know well how to use github, to make them readable.

It looks like the main goal is to prevent people from creating new
branches by mistake, but I've never done that, and it seems unlikely
to happen, since I interact with the repository exclusively from the
command line using codereview, and the tool probably doesn't even know
what github is, let alone how to push branches there.

I don't know what exactly a "social engineering attack" is, but I'm
also pretty sure no one will ever be able to convince me to create a
github release through sheer persuasion.

This change clearly has downsides, since we wouldn't just be taking
away rights to do things people are not supposed to do anyway (like
pushing a branch or creating a release), but also rights to do things
that some people -e.g. me- have been doing on the issue tracker.

@mvdan
Copy link
Member

@mvdan mvdan commented Sep 17, 2020

I definitely want fewer people to have direct write access, but at the same time I agree with @ALTree. Hiding/deleting spam or hateful comments, locking heated threads, editing bad formatting, and transferring issues are the kind of actions I take on a weekly basis. Especially in the morning, well before the Go team wakes up, since pretty much all of them are in the US.

You could say that it wouldn't hurt that much to wait 4-6h to take action in those cases, but I would generally disagree. Early action is a good way to keep the issue tracker tidy.

Having said all the above, perhaps we should clarify how those moderator-like features should be used. For example, if a comment violates the code of conduct after a warning, should we hide or delete the comment? What about blatant cases like spam or trolling - are we OK with deleting those right away without a warning?

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Sep 17, 2020

The social engineering risk is not that you'd get conned into doing something, but that there is a large group of people who can make a fake release and probably compromise a lot of downstream users. As the project grows, we need to find ways not to grow the attack surface uncontrollably.

Transfering and locking can be implemented in gopherbot pretty easily. CoC violations should be reported so they can be tracked: just deleting or hiding witholds information from the CoC team later on when they have to decide on a user. Editing is indeed unfortunate.

It seems unlikely though that there are dozens of users who need that permission, so maybe we can have a gardeners and a moderators group.

@ALTree
Copy link
Member

@ALTree ALTree commented Sep 17, 2020

The social engineering risk is not that you'd get conned into doing something, but that there is a large group of people who can make a fake release and probably compromise a lot of downstream users.

Oh, right. You meant the other way around.

I still think it's not a particularly interesting attack vector. Unless I'm mistaken, "making a release" only lets me choose an existing commit to tag. Since we already gatekeep commits, the opportunity to make real damage seems limited. I would need an accomplice with commit rights to sneak something in the repo, and if I'm able to do that I wouldn't tag a release on it (which would just make it more likely that someone notices); I would just wait for the next scheduled release.

I guess I could wait for a vulnerability to pop up, tag a minor release that I'm pretending fixed the vulnerability (but actually it's on a vulnerable commit), and then try to convince the victim to install my bad release (but really quickly, or the force push from googlesource.com will delete it(?)). It seems a pretty contrived scenario to me.

@mvdan
Copy link
Member

@mvdan mvdan commented Sep 17, 2020

Transfering and locking can be implemented in gopherbot pretty easily.

I'm not a big fan of the extra "gopherbot please do X" comment notifications, but I assume it's the only option we have if we absolutely want more granular permission access.

CoC violations should be reported so they can be tracked

Fair enough. One could still report at the same time as hiding a comment, though, for example. They're not mutually exclusive.

@katiehockman
Copy link
Member

@katiehockman katiehockman commented Sep 17, 2020

One could still report at the same time as hiding a comment, though, for example. They're not mutually exclusive.

+1. It seems reasonable that someone could take a screenshot of the comment/interaction, delete or hide it, then send that screenshot over to the conduct@golang.org as an FYI. That's probably what we should be doing anyway, especially for clear violations. I'm not sure this has been explicitly documented though, and it probably should be once decisions are made. https://golang.org/conduct#conflict-resolution discusses it somewhat, but could be clearer imo.

Apologies if that is off-topic for the issue at hand, though. In general, I'm in favor of cleaning up our permissions for the repo 👍

@dmitshur
Copy link
Member Author

@dmitshur dmitshur commented Sep 17, 2020

Thanks for the thoughtful feedback @ALTree and others.

Even though the "go-approvers" group is documented as "People who can edit issues in the "go" repo", in reality some people in it take up much more than just issue triage and gardening, and so a sudden change to the Triage level would be prohibitively limiting and unwelcome. At the same time, we probably want and could allow many more people in the "gardener" role than we need in the "moderator" role.

This original issue was about exploring a small change to the existing "go-approvers" group, primarily to prevent accidental branch creation, but it seems that it cannot be done without disruption and needing further careful thought.

I suspect a better way to proceed could be to leave "go-approvers" alone at first, and create a new "gardeners" group with Triage level access. It will become easier to add new people to the group, and we can also move anyone who'd like to be moved. Or maybe another approach.

I'll move this back to NeedsInvestigation for now. It's likely we'll want to make some changes eventually, but it's not yet clear what exactly, and bigger changes are probably best to consider outside of scope of this specific issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.