Make filecoin-project/github-mgmt public for transparency on repo access and settings

[BigLep]

What is github-mgmt / github-as-code?

See https://github.com/ipdxco/github-as-code and https://github.com/ipdxco/github-as-code/blob/master/docs/ABOUT.md , but in a nutshell github-as-code lets people make PRs against yml files to make repository changes rather than clicking through the UI. This has the benefits of:

1. Transparent - you can see who are making what changes
2. Reviewable before committing - double check through a PR that the intended changes are what are desired
3. Documentation - there is now a record in the PR (and optionally comments) why a certain change was made
4. Bulk changes - one PR can make changes across multiple repos if needed.
5. Easy to revert - when mistakes happen you can go back to previous state with a revert

What is the state of github-mgmt / github-as-code within filecoin-project currently as of 2024-07-19?

https://github.com/filecoin-project/github-mgmt exists but is currently private to a few users. It was setup in the event of needing to do a bulk permissions change in response to a security or operational event. (It's called github-mgmt because that was the name at the time. The public project has renamed to github-as-code to be more self-describing.)

What is the state of github-as-code in other ecosystems?

Related and dependency projects like IPFS, libp2p, IPLD, multiformats have used github-as-code with success for a couple of years. Example: https://github.com/ipfs/github-mgmt

Proposal

Make https://github.com/filecoin-project/github-mgmt public to view (while still restricting who can write to the repo as those with write access effectively have org owner permissions either directly or via escalating their role within the org through github-mgmt). This would allow for self-service and self-documenting conversations about who has certain permissions within filecoin-project, particularly large-blast radius permissions like org ownership.

Pros

1. We have a good, high context, public forum for discussing and documenting permission changes.
2. It's self-service for someone to know who to reach out to if they need help within a certain activity on GitHub (e.g., who the repo owners are).
3. There is a public history of repo changes which can be selectively reverted if needed. Even changes made through the GitHub UI will flow to filecoin-project/github-mgmt when it periodically syncs with GitHub. These syncs show up as additional commits.

Cons

1. It's fully clear who has what access to what repos for anyone on the internet (even if they're not a member of the filecoin-project). Any "security through obscurity" we had in the past will be gone. It will be clear who to specifically target in an attack if one wants to achieve a certain level of access.
2. github-as-code isn't setup in my opinion to manage changes for a diverse set of repos and stakeholders like filceoin-project. As discussed above, having write permissions to filecoin-project/github-mgmt is effectively like having org owner permissions. As a result, you want to limit who has such permissions. That is in tension though with each repo/team being able to manage their permissions independently. In order for that to happen, each team would need representation with having write access to filecoin-project/github-mgmt. An issue has been filed with github-as-code to support a diverse set of owners while limiting blast radius. Until this situation gets approved, we probably can't set the expectation that all repos can start managing permissions and settings through filecoin-project/github-as-code because I assume there won't be a small committee that is willing to merge PRs for changes to repos they are unaffiliated with.

Next Steps

1. I will plan to execute on the proposal by the end of the week of 2024-07-22 2024-07-29 if there isn't new information or major pushback.
2. If/once the repo becomes public, I'll create an issue to reduce filecoin-project org owner permissions because I believe it has built up a lot of cruft over the years.

[wolfduan]

github

[jennijuju]

proposal LGTM

question: is repo admin's the one needs to approve the PR for the change to be applied? or the responsibility falls under org owners (in which id like to avoid)?

[BigLep]

In order to enact my proposal, someone with push permissions will need to approve filecoin-project/github-mgmt#46 (which only those with repo access can currently see). That will cause the repo to become public. You @jennijuju and @galargh are a couple of the people with the ability to approve (plus a couple of others who aren't as involved with the project anymore - this is something I'll cleanup once the repo becomes public).

[jennijuju]

@BigLep sorry let me clarify my question, once github-mgmt is enabled in this github org, can repo's admin approve the PRs that updates the perms towards their repo, or it needs github org owners to do so?

[BigLep]

Got it - thanks.

once github-mgmt is enabled in this github org, can repo's admin approve the PRs that updates the perms towards their repo, or it needs github org owners to do so

Unfortunately a repo admin will not be able to merge filecoin-project/github-mgmt changes that affect their repo (unless they happen to also have push access to filecoin-project/github-mgmt). I assume this will generally not be the case because we'll want to highly limit the set of people with filecoin-project/github-mgmt push access. This is con number 2 that I'm getting at above (but I agree that isn't stated very well). In order to allow every repo to manage its permissions through a central filecoin-project/github-mgmt, github-as-code itself needs to improve. I put an issue on their backlog for this (ipdxco/github-as-code#126 ), but I'm not aware of any commitment to do this work, and I certainly don't think it would be done before we flip filecoin-project/github-mgmt public.

I still think it's worth having github-mgmt public though so we can handle some cross-org issues (e.g., reduce the set of org owners) and to empower a subset of teams to start using the tool and set a new precedent (even as github-as-code itself is getting improved behind the scenes to scale for more filecoin-project teams). For example, given FilOz maintains many repos in filecoin-project and is a known and trusted team in the ecosystem, I'd vote that they have the ability to start using this tool (with trusted understanding that they only use it to manage permissions for repos they maintain).

[BigLep]

No pushback so far, but I won't plan on executing on this until end of next week (week of 2024-07-29). nv23 upgrade activities and personal vacation/travel are taking priority.

[BigLep]

For visibility, this was completed with the closing of filecoin-project/github-mgmt#45. I'm going to "close" this discussion.