[Tracking Issue] "Interplanetary Stack" Github permissions cleanup 2024Q1

[BigLep]

GitHub orgs in scope

• ipfs
• libp2p
• ipld
• multiformats
• ipfs-shipyard
• ipfs-examples

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:

1. small (2-5) to reduce risk
2. active in the org because they are more likely to make informed decisions
3. representative of multiple independent companies/teams

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:

1. Moving inactive org members to an "Alumni team"
2. Deleting inactive teams
3. Pruning members and teams from repos that they are no longer active on.

Because this can result in a lot of changes, it's important to both:

1. @mention those affected
2. Give a clear summary about how they're affected. This is being handled in Give a user-oriented view of permissions and changes ipdxco/github-as-code#113

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:

1. No longer have team members with access permission. (See Be prescriptive on archived repos (including removing permissions) ipdxco/github-as-code#116 for more info.)
2. Not clutter permissions review/management for the repos that are active. (See Remove clutter resulting from archived repos ipdxco/github-as-code#115 for more info.)

Status Table

Org	Reduce Org Owners	"Archive" inactive users and teams	Strip permissions to archived repos
ipfs	✅ ipfs/github-mgmt#189
libp2p	✅ libp2p/github-mgmt#202
ipld	✅ ipld/github-mgmt#68 ✅ ipld/github-mgmt#69
multiformats	✅ multiformats/github-mgmt#85 ✅ multiformats/github-mgmt#90
ipfs-shipyard	✅ ipfs-shipyard/github-mgmt#71
ipfs-examples	✅ https://github.com/ipfs-examples/github-mgmt/pull/30

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:

1. Important messaging about these projects is communicated through these repos, whether in readmes or websites sourced in the repos.
2. Many of the libraries and tools in these repos are depended on by projects other projects, some of which have large financial balances or reputations at stake. We want to reduce the ability of malicious actors' ability to introduce vulnerabilities/bugs when they compromise a member's account.
3. "Clear is kind" - Archiving unmaintained repos and adjusting members who have been inactive for large periods of time helps give a signal to the current state of a project and makes it clearer who someone should reach out to for help.

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

• libp2p cleanup in 2022: chore: clean up inactive users from the org, teams and repos libp2p/github-mgmt#12
• Initial ipld cleanup in 2024: WIP: Remove inactive members, collaborators and teams ipld/github-mgmt#65

[BigLep]

Immediate next steps:

1. (Expected date for PRs to be created: 2024-02-09): @BigLep to get the "Reduce org owners" PRs created (and added to the summary table)
2. (Expected date for PRs to be created: 2024-02-14): @galargh to address Give a user-oriented view of permissions and changes ipdxco/github-as-code#113

[dhuseby]

This set of ["org owners"] people should be:
...
3. representative of multiple independent companies/teams

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.

[BigLep]

(Expected date for PRs to be created: 2024-02-09): @BigLep to get the "Reduce org owners" PRs created (and added to the summary table)

I didn't get to this on Friday, 2024-02-09. I'll be doing on 2024-02-12.

[BigLep]

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.

[BigLep]

"Reduce Org Owners" PRs have been created and are tracked in the issue description.

The plan is to get those merged 2024-02-14.

[BigLep]

@dhuseby:

This set of ["org owners"] people should be:
...
3. representative of multiple independent companies/teams

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.

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

[BigLep]

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.

[BigLep]

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:

1. Likely too extreme of an operational posture given there are no paying customers here. (I'm assuming amongst PL Inc nucleations that org owner permissions are getting flexed quite a bit right now in moving things around, cleaning up, etc.)
2. There are likely notifications that come through to owners that it would be risky to not have any human receiving.

Feedback welcome though if anyone thinks we should tighten further.

[olizilla]

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?

[BigLep]

I should have updated earlier on where things are at.
I'm investigating how to tighten up the org owner role further. I'll report back more today.
@galargh and I are meeting on 2024-02-16 so we can review his work in ipdxco/github-as-code#115 and ipdxco/github-as-code#113 which should unblock phase 2: "'Archive' inactive users and teams"
More to come.

[BigLep]

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.

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:

1. Reduce org owners to:
   • @galargh: co-founder of IPDX, and IPDX is contracted to look after github for this organization.
   • @andyschwab-admin: leader of Sodal, has close access to sead which is charged with sysadmin around these organizations, and general long-standing sysadmin for these organizations with his past roles at PL Inc
2. Remove all existing org owners and just have the reduced set from the recent PRs in the "github-mgmt Stewards" teams.
3. Give the "github-mgmt Stewards" team "moderator" and "security manager" roles.
   • I don't think this is something that can be done through github-mgmt. For example, I don't see any useful docs when searching Terraform's docs. It would need to be a one-time action through the GitHub UI.

---

can it be explicitly documented why those who have been granted this power have it

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-mgmt

collapsed table

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

GitHub Docs Website Order (2024-02-15)	Organization permission	Way To Handle	Way To Handle Comment	Owners	Members	Moderators	Billing managers	Security managers
24	Block and unblock non-member contributors (see " Blocking a user from your organization ")	handled by moderator role		✔️	❌	✔️	❌	❌
25	Limit interactions for certain users in public repositories (see " Limiting interactions in your organization ")	handled by moderator role		✔️	❌	✔️	❌	❌
39	Limit activity in public repositories in an organization	handled by moderator role	can also be handled by repo moderators	✔️	❌	❌	❌	❌
31	Manage security and analysis settings (see " Managing security and analysis settings for your organization ")	handled by security moderator role		✔️	❌	❌	❌	✔️
36	Receive Dependabot alerts about insecure dependencies for all of an organization's repositories	handled by security moderator role		✔️	❌	❌	❌	✔️
37	Manage Dependabot security updates (see " About Dependabot security updates ")	handled by security moderator role		✔️	❌	❌	❌	✔️
40	Pull (read) all repositories in the organization	handled by security moderator role		✔️	❌	❌	❌	✔️
14	Delete all teams	‼️ should require explicit escalation of permissions	don't ever want to do	✔️	❌	❌	❌	❌
15	Delete the organization account, including all repositories	‼️ should require explicit escalation of permissions	don't ever want to do	✔️	❌	❌	❌	❌
41	Push (write) and clone (copy) all repositories in the organization	‼️ should require explicit escalation of permissions	this is rare or never need	✔️	❌	❌	❌	❌
33	Transfer repositories	escalate when needed	this will provide some friction as it's needed from time-to-time, especially during reorg and cleanup seasons.	✔️	❌	❌	❌	❌
12	Access the organization audit log	escalate in lower freqency cases	This is something we'd be fine to be more public. Maybe IPDX can expose or snapshot this more publicly.	✔️	❌	❌	❌	❌
13	Edit the organization's profile page (see " About your organization's profile ")	escalate in lower freqency cases		✔️	❌	❌	❌	❌
34	Purchase, install, manage billing for, and cancel GitHub Marketplace apps	escalate in lower freqency cases	this isn't common	✔️	❌	❌	❌	❌
45	Manage default labels (see " Managing default labels for repositories in your organization ")	escalate in lower freqency cases	this isn't common	✔️	❌	❌	❌	❌
4	Edit and cancel invitations to join the organization	escalate if ever needed	this isn't common since github-mgmt will trigger the invites	✔️	❌	❌	❌	❌
30	Manage the publication of GitHub Pages sites from repositories in the organization (see " Managing the publication of GitHub Pages sites for your organization ")	escalate if ever needed	already enabled; doesn't need to be toggled	✔️	❌	❌	❌	❌
35	List apps in GitHub Marketplace	escalate if ever needed	this isn't common	✔️	❌	❌	❌	❌
38	Manage the forking policy	escalate if ever needed	already disabled and likely doesn't need to be toggled again	✔️	❌	❌	❌	❌
44	Manage the default branch name (see " Managing the default branch name for repositories in your organization ")	escalate if ever needed	already set and likely doesn't need to be adjusted	✔️	❌	❌	❌	❌
22	Hide comments on writable commits, pull requests, and issues (see " Managing disruptive comments ")	handled at the repo level	anyone with write access to a repository can handle	✔️	✔️	✔️	❌	✔️
23	Hide comments on all commits, pull requests, and issues (see " Managing disruptive comments ")	handled at the repo level	anyone with write access to a repository can handle	✔️	❌	✔️	❌	✔️
46	Manage pull request reviews in the organization (see " Managing pull request reviews in your organization ")	handled at the repo level		✔️	❌	❌	❌	❌
9	Configure code review assignments (see " Managing code review settings for your team ")	team maintainer can handle		✔️	❌	❌	❌	❌
10	Set scheduled reminders (see " Managing scheduled reminders for your team ")	team maintainer can handle		✔️	❌	❌	❌	❌
26	Set a team profile picture in all teams (see " Setting your team's profile picture ")	team maintainer can handle		✔️	❌	❌	❌	❌
1	Create repositories (see " Restricting repository creation in your organization ")	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
16	Create teams (see " Setting team creation permissions in your organization ")	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
18	Create projects (see " Project (classic) permissions for an organization ")	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
19	See all organization members and teams	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
20	@mention any visible team	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
21	Can be made a team maintainer	n/a	member permission covers it	✔️	✔️	✔️	❌	✔️
2	View and edit billing information	n/a	Organization is on free plan. Billing managers can be added separately (e.g., IPFS Foundation)	✔️	❌	❌	✔️	❌
32	View security overview for the organization (see " About security overview ")	n/a	not relevant since don't use GitHub Enterprise	✔️	❌	❌	❌	✔️
43	View people with access to an organization repository	n/a	already self-service for world by viewing github-mgmt publicly. No permisisons needed.	✔️	❌	❌	❌	❌
3	Invite people to join the organization	normal github-mgmt PR case		✔️	❌	❌	❌	❌
5	Remove members from the organization	normal github-mgmt PR case		✔️	❌	❌	❌	❌
6	Reinstate former members to the organization	normal github-mgmt PR case		✔️	❌	❌	❌	❌
7	Add and remove people from all teams	normal github-mgmt PR case		✔️	❌	❌	❌	❌
8	Promote organization members to team maintainer	normal github-mgmt PR case		✔️	❌	❌	❌	❌
11	Add collaborators to all repositories	normal github-mgmt PR case		✔️	❌	❌	❌	❌
17	Move teams in an organization's hierarchy	normal github-mgmt PR case		✔️	❌	❌	❌	❌
42	Convert organization members to outside collaborators	normal github-mgmt PR case		✔️	❌	❌	❌	❌
27	Sponsor accounts and manage the organization's sponsorships (see " Sponsoring open source contributors ")	defer	not critical to account for currently	✔️	❌	❌	✔️	✔️
28	Manage email updates from sponsored accounts (see " Managing updates from accounts your organization sponsors ")	defer	not critical to account for currently	✔️	❌	❌	❌	❌
29	Attribute your sponsorships to another organization (see " Attributing sponsorships to your organization " for details )	defer	not critical to account for currently	✔️	❌	❌	❌	❌

[lidel]

(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 assignees pre-filled up.

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.

[BigLep]

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.

[BigLep]

2024-02-16 update concerning phase 2: "Archive" inactive teams and users

This 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 users

PR title: "Archiving" inactive teams and users 2024Q1

PR Description

Summary

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

Timeline

2024-02-XX: public PR
2024-02-XX: notify affected parties with @mention: LINK_TO_COMMENT_IN_THIS_PR
2024-02-XX: merge this change after incorporating feedback

Reviewer's Checklist

• It is clear where the request is coming from (if unsure, ask)
• All the automated checks passed
• The YAML changes reflect the summary of the request
• The Terraform plan posted as a comment reflects the summary of the request

PR comment @mentioning affected parties

Comment message

$LIST_OF_PEOPLE_TO_@MENTION

We'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.

[Stebalien]

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.