-
Notifications
You must be signed in to change notification settings - Fork 314
Remove explicit write/maintain permissions mods had on some repos #1848
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
Conversation
Just a minor concern, there is one repo that is very sensitive (crates.io-index) which has pretty much zero human oversight, and a nearly non-existent branch protection. I personally would like to see that repo's permissions tightened somehow to minimize access as much as possible instead of expanding access. (It's not that I don't trust the mods, but the more people with access leaves more opportunities for leaked keys and such.) I'm not sure what the answer is there, because there are still vandals who do things like leave comments on commits. Would it be worthwhile to create a custom role? |
so without write access you can still moderate but you need to do more clicks? 🤔 |
I agree that some repos might want to have access tightened down. Other examples are repos where only infra-admins can merge changes. It might be worth to add a |
This would open the scope of the threat model regarding any supply chain attacks and malicious GitHub things to include the entire mod team globally, and not just t-infra. There are a lot of other granular scopes within the GitHub projects we defer security to access control, which wouldn't be commonly monitored even in the high profile repos. Things like workflows, actions, etc. are all scoped under write. |
fwiw: the not being able to moderate ppl from the comment is not a real issue, just a side effect I noticed. The real power I want is to be able to lock threads and to be able to unhide comments I would be much happier not having write perms in repos outside of what my other teams give me |
@ehuss where is this happening, and how |
Like this: rust-lang/crates.io-index@8ec6b4e#r143152289 Anyone can click on any commit and add comments to them. It's fairly rare, though. |
We designate the mods team as moderators in GitHub:
@oli-obk can you screenshot the menu you're referring to perhaps? I wonder if this is 'just' a bug in the UI if you're saying that you can already take all relevant actions but have to do it through a more complicated path... |
hmm... i don't know what I did wrong before or whether I misinterpreted sth, but I definitely cannot reproduce now. I guess I'll leave the issue/PR locking to ppl with write powers. Everything else already is useful enough. I'll edit this PR to remove or lower mod powers where they unnecessarily had them |
write
permissions on all public repos
Dry-run check results
|
cc @rust-lang/infra @rust-lang/leadership-council
~~We've had trouble before with not being able to lock issues/PRs in some repos and performing moderation actions on individuals is harder if one doesn't have at least write access (the menu isn't there, so I have to go through the organization settings)
This PR automatically injects the mod team into all (non-private!) repos with write access. This is obviously not the ideal state, but effectively what we were doing anyway, just manually (and sometimes thus wrongly giving "maintain" access)~~
This PR removes mod permissions, as we do not need to change the repos themselves (except for mod repos and the
team
repo)