You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reduce org ownership to only a couple of people since "org owners" have the ability to impact the github org as a whole and every repo in the org (docs). This includes destructive one-way operations like repo deletion. These people should:
be active in the filecoin-project org because they are more likely to make informed decisions and
Review/reduce 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 group should be:
still small (5-8)
active in the org because they are more likely to make informed decisions
representative of multiple independent companies/teams
There should be comments above each username that has "org owner like" permissions providing a justification.
Why Important
This is the lowest-hanging fruit to protect the filecoin-project org around overly generous permissions. 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:
We want to reduce the ability of malicious actors' ability to introduce vulnerabilities/bugs when they compromise a member's account.
We want to reduce the possibility that someone's account could be compromised and then destructive actions are taken like deleting repos.
Communication Channels
This issue and the connected PRs are intended to be the main communication channels.
Background
The filecoin-project org has 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 Filecoin having more and more independent teams, we're overdue on cleaning up permissions and reevaluating past assumptions.
Notes
I don't think giving moderator and security operator roles to a team can be one through github-mgmt itself. 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 rather than through github-mgmt.
## Tasks
- [x] Temporarily escalate @BigLep permissions so can view the [audit log](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization) and give the moderator and security manager permissions to the newly created teams in https://github.com/filecoin-project/github-mgmt/pull/60
- [x] PR for proposing/doing the corresponding permissions changes including the related communication: https://github.com/filecoin-project/github-mgmt/pull/61
- [x] Give the "moderators" team moderator permissions.
- [x] Give the "security-managers" team security manager permissions
- [ ] ~Revoke @BigLep's escalated permissions~ Per #61, he is keeping permissions through 2024-12-31.
- [ ] https://github.com/filecoin-project/github-mgmt/issues/65
Done Criteria
Why Important
This is the lowest-hanging fruit to protect the filecoin-project org around overly generous permissions. 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:
Communication Channels
This issue and the connected PRs are intended to be the main communication channels.
Background
The filecoin-project org has 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 Filecoin having more and more independent teams, we're overdue on cleaning up permissions and reevaluating past assumptions.
Notes