-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
[Tracking Issue] "Interplanetary Stack" Github permissions cleanup 2024Q1 #511
Comments
Immediate next steps:
|
I like this a lot but for libp2p right now, there is no formal structure for "org owners". Other open source projects I've worked with have had standing "technical steering committees" for this purpose. I'm just pointing out that the roles with responsibility should probably map to real-world groups with official standing. |
I didn't get to this on Friday, 2024-02-09. I'll be doing on 2024-02-12. |
FYI that I I'm not including ipfs-inactive since it currently doesn't have github-mgmt. Here is the current membership per https://github.com/orgs/ipfs-inactive/people: @lidel : not required, but I leave it up to you as one of the current org owners whether you want want to prune some of the folks who aren't as active anymore. |
"Reduce Org Owners" PRs have been created and are tracked in the issue description. The plan is to get those merged 2024-02-14. |
Ack, makes sense. As part of the "2024 libp2p growing up" work, there is a steering committee that is intended to be set up. It seems like it would be good to map to the groups involved with that. In the meantime, I am making a best effort of using tribal knowledge that we have to make this better than it was (e.g., too many org owners/admins, many of which are not actively involved in the project anymore.) |
Doh - I'm realizing I didn't have multiformats on the list of in-scope orgs. Doh! My bad! That wasn't intentional. I'm adding it now and getting started on the org owner/admin cleanup. |
Documenting some thoughts that occurred while responding on what to do concerning some foundational-but-not-currently-active-in-github team members: I was wondering about going to a larger extreme of effectively removing all org owners and then just relying on github-mgmt stewards to self-promote themselves to "org owner" when they need this (leaving a comment for why they need this and what conditions need to be met to be removed from the owner role). This seems like the safest thing to reduce the chance that org owners accidentally use their permissions in unintended ways (and reduces some of the potential blas radius if their account gets hacked - there would at least be a PR to github-mgmt that would show the escalation of permissions which may give someone the chance to react/response.) I sided against advocating for this because:
Feedback welcome though if anyone thinks we should tighten further. |
The current "almost secure but not quite" position is humane but logically untenable. Tighten it up as you suggest so everyone has to apply for the perms they need, or leave them as they are. If the proposal here is to remain as is then please can it be explicitly documented why those who have been granted this power have it. What orgs are they representing? Which orgs are sufficiently ipfs/ipld/etc enough to count? |
I should have updated earlier on where things are at. |
Good comment. Generally, I don't think we should let best be the enemy of better (e.g., getting down to 6 individuals who are active in an org is better than 20 people many of which haven't been active in years even if it's not the ideal solution). That said, I looked harder at what it would be like to really reduce the org owner permissions. I went through all permissions listed in github org role docs and then listed how I think they could/should be handled (see the collapsed table at the bottom). Going through this exercise is leading me to propose:
Yeah, I can start the precedent of documenting everyone in the "github-mgmt Stewards" role. I'm going to update/create PRs for ipfs/libp2p/IPLD incorporating this proposal above and will report back when they're done. github org role permissions and suggestion on how to handle in light of github-mgmtcollapsed tableThe data below started from https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles . The Owners, Members, Moderators, Billing managers, and Security managers columns are directly from Github docs. It was augmented and sorted in this public spreadsheet. The copy/paste below causes the hyperlinks to be lost. If you want those, go to the spreadsheet.
|
(As someone who had owner status for years) I think limiting surface for security problems is a net positive. In theory, the set of things that can only be done by owners will be limited, and they won't be needed often. I do a repo transfer once or twice a quarter. For needs like that we can go with LO-FI solution and have issue templates in github-mgmt for owner-only operations like "transferring repository" with In practice there will be unexpected disruptions, but the need does not occur often, we would discover gaps and create additional templates/playbooks as the needs arise. |
Phase 1 to reduce org owners is complete. Thanks to all for the feedback here. We ended up reducing org ownership to just a couple of individuals, giving additional permissions to the "github-mgmt stewards" teams (moderator and security manager org roles), and documenting why all the github-mgmt stewards members are on the respective team. |
2024-02-16 update concerning phase 2: "Archive" inactive teams and usersThis should be ready to start week of 2024-02-19. @galargh demoed to me the work in ipdxco/github-as-code#113 and ipdxco/github-as-code#115 . These will clean up the diffs substantially when inactive users get "archived" and make them easier to reason about. I personally won't be driving this next phase. @galargh and @lidel will be at the helm. Below is some starter messaging to help with this phase: PRs for "archiving" inactive teams and usersPR title: "Archiving" inactive teams and users 2024Q1 PR DescriptionSummaryThis pertains to the "'archive' inactive users and teams" in #511. Who is this targeting?The current PR is what results from a script to identify inactive teams users in an org. Some additional manual cleanup changes may have been done as well when looking at the repos. For example, the "w3dt-stewards" team is removed as it doesn't make sense in light of having github-mgmt now for that wide of a group of people to have admin permissions across so many repos. Why is this being done?See "Why do we care about periodically cleaning up permissions across the orgs?" in #511 Is this set in stone?No. This PR was created and being left open for some days to give awareness and incorporate feedback. We're not taking a "ask for permission" approach as that would require way too much wrangling. Instead, we're giving visibility to what's proposed and invite folks to comment and influence. A saving grace here is that none of this is a "one-way door". If something got messed up or missed, a followup PR can be done to correct it. Is anyone being removed from the organization?No. All existing members of the org are staying members. In the most reduced/scoped-down case, someone will still be part of of an "Alumni" team in the org to signal their past involvement. Thank you for your past contributions, and we certainly welcome you to play a more active role in the future. Timeline2024-02-XX: public PR Reviewer's Checklist
PR comment @mentioning affected partiesComment message$LIST_OF_PEOPLE_TO_@MENTIONWe're @mentioning you to inform you that your $ORG_NAME github "org ownership" permissions will be adjusted as part of a #511 unless you respond back with your use-case for having these permissions by 2024-02-XX. You can read more about the purpose and motivation for the changes in the PR description. To see how this proposed change is affecting you see $LINK_TO_DIFF_OF_USER_FOCUSED_VIEW_OF_PERMISSION_CHANGES. You can also see the access you have currently (and via what means) at $LINK_TO_DUMP_OF_USER_FOCUSED_VIEW_OF_PERMISSIONS_CURRENTLY_IN_MAIN This isn't a one-way door. If we got this wrong or you don't see the notification after the merge date above, a new PR can be created to fix permissions at $ORG_NAME/github-mgmt. Thanks and let us know if you have any questions or concerns. |
With respect to PRs like ipfs/github-mgmt#193... I think we should merge this, but I'd go even further and remove repo and user specific permissions entirely in most cases, replacing them with teams. |
GitHub orgs in scope
Background
The Github orgs above have accumulated a lot of permissions over the years. This was somewhat acceptable/mitigated in the past by Protocol Labs Inc being a single company. As Protocol Labs Inc moves to an innovation network of companies (related blog) and projects like IPFS and libp2p maturing with independent foundations, funding, etc. (related blog), we're overdue on cleaning up permissions and reevaluating past assumptions.
For example, many of the repos have given admin access to a "w3dt-stewards" team. That was used when there was a small team who was charged with looking after the whole github org, and they didn't have github-mgmt at their disposal. In the PLv10 / PL Innovation Network era, there is no corrolary for this. If broad action is needed, it can be done broadly via github-mgmt. And where it can't be done directly with github-mgmt, github-mgmt can at least be done to give broad permissions to go do the broad action.
Approach
For each org above, the intent is to take the following actions. This may happen in multiple waves and each org may be on a different schedule.
Reduce "org owners"
"org owners" have the ability to impact the github org as a whole and every repo in the org (docs). This set of people should be:
In addition to looking at the direct "org owner", we need to look at who has push access to github-mgmt in the org, as that is an escalation path to "org ownership" as well. This translates to looking at the "github-mgmt stewards" team, since that team has push access to github-mgmt.
This is the lowest-hanging fruit item to do to protect the orgs, and it will be executed first/separately.
2024-02-15: further comments on this topic are in #511 (comment). We ended up reducing org ownership to just a couple of individuals, giving additional permissions to the "github-mgmt stewards" teams (moderator and security manager org roles), and documenting why all the github-mgmt stewards members are on the respective team.
"Archive" inactive users and teams
Note: there is no direct GitHub action for "archiving" an user and team. One can only archive a repo.
By archive we mean:
Because this can result in a lot of changes, it's important to both:
The logic for making this proposed change lives in https://github.com/ipdxco/github-as-code/blob/master/scripts/src/actions/remove-inactive-members.ts
Optional: other human-spotted improvements
Likely during the "archive inactive users and teams" phase, other opportunities to reduce permissions will be identified.
TBD: strip permissions to archived repos
If a repo is archived, it should ideally:
Status Table
Communication Channels
This issue and the connected PRs are intended to be the main communication channels.
For chat there is FIL Slack #ip-stack-github-permissions-cleanup-2024q1
FAQ
Why do we care about periodically cleaning up permissions across the orgs?
We're obviously not seeking to restrict access to code itself, and this isn't about checking some box for "good OpSec". Some reasons we care about the OpSec here include:
Why is this in ipfs/ipfs?
I needed a place somewhere to put a tracking issue. It seemed as good as anywhere. I'm not expecting anyone to find this organically. It will get linked to from PRs in the github-mgmt repos in the org above. I
Who is driving this effort?
@galargh from IPDX and @BigLep from PL Inc with support and review from many when the PRs get opened.
Related Items
The text was updated successfully, but these errors were encountered: