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

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