sleepy/forgejo

Fork 0

Feature Request: Multi-Owner Authorization (Quorum) for Sensitive Org-Level Actions #12451

New issue

Open

opened 2026-05-07 15:43:02 +02:00 by lsmith · 9 comments

lsmith commented

2026-05-07 15:43:02 +02:00

(Migrated from codeberg.org)

Existing problems this enhancement addresses

Currently, a single organization owner has the unilateral power to perform "destructive" or high-impact actions, such as transferring a repository to a different organization or deleting it entirely. This creates two major risks:

Account Compromise: If one owner’s credentials are stolen, the entire project's infrastructure is at risk.
Internal Misalignment: A single owner can act against the project’s governance (e.g., there was a recent incident like this within the CHAOSS project).

Enhancement description

Proposed Workflow:

Initiation: An owner triggers a sensitive action (e.g., Transfer Repository).
Pending State: The action is placed in a "Pending Approval" state. The repository remains in place but is locked for further transfers.
Notification: All owners receive a notification (email/in-app) regarding the request.
Verification: A configurable number of owners (e.g., 2, or a 51% quorum) must click "Approve."
Execution: Once the threshold is met, the action completes automatically.

Possible Configuration Options:

Threshold: "Require X owners to approve" or "Require $X$% of owners."
Expiry: A timeframe (e.g., 72 hours) after which the request expires if the quorum isn't met.
Scope: Options to toggle which actions require this (Transfer, Delete, Rename, Adding/Removing other Owners, Multi-Owner Authorization Configuration ..?).

Details and notes

Security vs. Governance:

This should be viewed strictly as a security layer. It is not intended to replace project governance or consensus-building, but rather to ensure that a single compromised account or rogue owner cannot hijacked a project's history and home.

The "Deadlock" Scenario:

What happens if the number of active owners falls below the required quorum?

Possible solution brought up by @zoe:
If after a predetermined period there is no (significant?) opposition, it is approved.

Audit Logs:

Not sure if there should be an audit log?

### Existing problems this enhancement addresses Currently, a single organization owner has the unilateral power to perform "destructive" or high-impact actions, such as transferring a repository to a different organization or deleting it entirely. This creates two major risks: * Account Compromise: If one owner’s credentials are stolen, the entire project's infrastructure is at risk. * Internal Misalignment: A single owner can act against the project’s governance (e.g., there was a recent incident like this within the CHAOSS project). ### Enhancement description Proposed Workflow: * Initiation: An owner triggers a sensitive action (e.g., Transfer Repository). * Pending State: The action is placed in a "Pending Approval" state. The repository remains in place but is locked for further transfers. * Notification: All owners receive a notification (email/in-app) regarding the request. * Verification: A configurable number of owners (e.g., 2, or a 51% quorum) must click "Approve." * Execution: Once the threshold is met, the action completes automatically. Possible Configuration Options: * Threshold: "Require $X$ owners to approve" or "Require $X$% of owners." * Expiry: A timeframe (e.g., 72 hours) after which the request expires if the quorum isn't met. * Scope: Options to toggle which actions require this (Transfer, Delete, Rename, Adding/Removing other Owners, Multi-Owner Authorization Configuration ..?). ### Details and notes #### Security vs. Governance: This should be viewed strictly as a security layer. It is not intended to replace project governance or consensus-building, but rather to ensure that a single compromised account or rogue owner cannot hijacked a project's history and home. #### The "Deadlock" Scenario: What happens if the number of active owners falls below the required quorum? Possible solution brought up by @zoe: If after a predetermined period there is no (significant?) opposition, it is approved. #### Audit Logs: Not sure if there should be an audit log?

Gusted commented

2026-05-07 15:51:44 +02:00

(Migrated from codeberg.org)

@wetneb is this by any chance within the area you wanted to work on for organizations?

zoe commented

2026-05-07 15:58:18 +02:00

(Migrated from codeberg.org)

Verification: A configurable number of owners (e.g., 2, or a 51% quorum) must click "Approve."

Just a thought here. That would also require being able to change it. The code would need to ensure, that an owner cannot just change this value to 1 and then delete.

So maybe a quorum change would also need to be configurable. Also would have to think about deadlock situations (what if someone becomes inactive, is not reachable anymore and thus cannot Approve a change).

Expiry: A timeframe (e.g., 72 hours) after which the request expires if the quorum isn't met.

Even a waiting period would be good in general. If the minimal quorum is met it is executed directly. Otherwise after a (predetermined time) it is also executed unless the number of "disagrees" is higher.

This would solve the first problem.

Also imagine a bad actor adding enough people to the Owners Team and then letting them all execute the action (I do not have a solution for that).

> Verification: A configurable number of owners (e.g., 2, or a 51% quorum) must click "Approve." Just a thought here. That would also require being able to change it. The code would need to ensure, that an owner cannot just change this value to 1 and then delete. So maybe a quorum change would also need to be configurable. Also would have to think about deadlock situations (what if someone becomes inactive, is not reachable anymore and thus cannot Approve a change). > Expiry: A timeframe (e.g., 72 hours) after which the request expires if the quorum isn't met. Even a waiting period would be good in general. If the minimal quorum is met it is executed directly. Otherwise after a (predetermined time) it is also executed unless the number of "disagrees" is higher. This would solve the first problem. Also imagine a bad actor adding enough people to the Owners Team and then letting them all execute the action (I do not have a solution for that).

lsmith commented

2026-05-07 16:02:05 +02:00

(Migrated from codeberg.org)

@zoe wrote in https://codeberg.org/forgejo/forgejo/issues/12451#issuecomment-14450666:

Just a thought here. That would also require being able to change it. The code would need to ensure, that an owner cannot just change this value to 1 and then delete.

yeah all the settings related to this enhancement should also be protectable.

Even a waiting period would be good in general. If the minimal quorum is met it is executed directly. Otherwise after a (predetermined time) it is also executed unless the number of "disagrees" is higher.

Yeah that is a good idea to auto-execute if there isn't opposition after the predetermined time as it indeed elegantly handles the Deadlock Scenario. It just means you have to wait a bit longer.

@zoe wrote in https://codeberg.org/forgejo/forgejo/issues/12451#issuecomment-14450666: > Just a thought here. That would also require being able to change it. The code would need to ensure, that an owner cannot just change this value to 1 and then delete. yeah all the settings related to this enhancement should also be protectable. > Even a waiting period would be good in general. If the minimal quorum is met it is executed directly. Otherwise after a (predetermined time) it is also executed unless the number of "disagrees" is higher. Yeah that is a good idea to auto-execute if there isn't opposition after the predetermined time as it indeed elegantly handles the `Deadlock Scenario`. It just means you have to wait a bit longer.

lsmith commented

2026-05-07 16:29:29 +02:00

(Migrated from codeberg.org)

FYI Github enterprise has some capabilities in this direction https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/governing-how-people-use-repositories-in-your-enterprise

matkoniecz commented

2026-05-07 17:36:02 +02:00

(Migrated from codeberg.org)

Note that for single-owner projects extra fiddling should not be introduced (if I fully control project I want to be able to delete/move/whatever it).

Though opt-in may be wanted, to limit damage in case of a hack?

Note that for single-owner projects extra fiddling should not be introduced (if I fully control project I want to be able to delete/move/whatever it). Though opt-in may be wanted, to limit damage in case of a hack?

matkoniecz commented

2026-05-07 17:36:53 +02:00

(Migrated from codeberg.org)

Just a thought here. That would also require being able to change it. The code would need to ensure, that an owner cannot just change this value to 1 and then delete.

another attack would be adding 20 dummy accounts as co-owners and voting with such sockpuppets to approve move

or kicking out co-owners/co-maintainers and then performing restricted action

> Just a thought here. That would also require being able to change it. The code would need to ensure, that an owner cannot just change this value to 1 and then delete. another attack would be adding 20 dummy accounts as co-owners and voting with such sockpuppets to approve move or kicking out co-owners/co-maintainers and then performing restricted action

matkoniecz commented

2026-05-07 17:38:05 +02:00

(Migrated from codeberg.org)

Expiry: A timeframe (e.g., 72 hours) after which the request expires if the quorum isn't met.

maybe minimal time instead? so no matter what some action cannot be taken within first 24h?

(though there may be a valid reason for immediate action to be taken....)

> Expiry: A timeframe (e.g., 72 hours) after which the request expires if the quorum isn't met. maybe minimal time instead? so no matter what some action cannot be taken within first 24h? (though there may be a valid reason for immediate action to be taken....)

wetneb commented

2026-05-07 21:11:18 +02:00

(Migrated from codeberg.org)

That being said, one way of making this danger less of an issue would be to reduce the need to make people "Owners" of organizations in the first place. Which can be done in various ways (both of which I am interested in exploring):

making it possible to grant some privileges that are currently Owner-only to other teams. For instance, only owners can add new members to teams, but one could imagine other ways to do that: certain teams could be allowed to co-opt members (any member of that team can add other members) or that members of team A are able to add new members of team B.
enabling a "git-ops" style of organization/repo settings. Meaning that the settings of an organization or repo are mirrored by some files in a git repository, on which people can do PRs, have branch protection rules, and so on. I have been doing some research on the existing solutions for this: https://codeberg.org/wetneb/todo/issues/3 (designed to be notes for myself, may not be super understandable for others yet). Practically speaking, I am considering working on, in order of ambition:
1. external tooling (as actions, or external web services) to ease the management of a Forgejo org/repo via git
2. considering integrating some of that logic in Forgejo itself (a form of magic repos: https://codeberg.org/forgejo/design/issues/21)
3. potentially, adding UI sugar on top of such a magic repo feature to open/review PRs on such repos for specific kinds of proposals (such as nominations of people in certain roles).

That's a really interesting issue, thanks for the ping @Gusted. It does fit the overall scope of my work interests. It seems difficult to design something around this specific actions (transfer, deletion, archival). That being said, one way of making this danger less of an issue would be to reduce the need to make people "Owners" of organizations in the first place. Which can be done in various ways (both of which I am interested in exploring): * making it possible to grant some privileges that are currently Owner-only to other teams. For instance, only owners can add new members to teams, but one could imagine other ways to do that: certain teams could be allowed to co-opt members (any member of that team can add other members) or that members of team A are able to add new members of team B. * enabling a "git-ops" style of organization/repo settings. Meaning that the settings of an organization or repo are mirrored by some files in a git repository, on which people can do PRs, have branch protection rules, and so on. I have been doing some research on the existing solutions for this: https://codeberg.org/wetneb/todo/issues/3 (designed to be notes for myself, may not be super understandable for others yet). Practically speaking, I am considering working on, in order of ambition: 1. external tooling (as actions, or external web services) to ease the management of a Forgejo org/repo via git 2. considering integrating some of that logic in Forgejo itself (a form of magic repos: https://codeberg.org/forgejo/design/issues/21) 3. potentially, adding UI sugar on top of such a magic repo feature to open/review PRs on such repos for specific kinds of proposals (such as nominations of people in certain roles).

aahlenst commented

2026-05-07 21:28:46 +02:00

(Migrated from codeberg.org)

@wetneb wrote in https://codeberg.org/forgejo/forgejo/issues/12451#issuecomment-14463461:

That being said, one way of making this danger less of an issue would be to reduce the need to make people "Owners" of organizations in the first place.

I don't think that this issue can really be solved by trying to circumvent it. As long as there are owners, there can be problems. https://www.theregister.com/software/2025/09/25/open-source-to-closed-doors-rubygems-control-fight-erupts/1440976 is another example how it can play out.

enabling a "git-ops" style of organization/repo settings.

In Forgejo Actions, I'm striving for moving things out of the Git repository into the settings. Having settings in the Git repository is a giant headache because almost everybody has write access to the repository. That makes things like permissions in workflows almost pointless.

@wetneb wrote in https://codeberg.org/forgejo/forgejo/issues/12451#issuecomment-14463461: > That being said, one way of making this danger less of an issue would be to reduce the need to make people "Owners" of organizations in the first place. I don't think that this issue can really be solved by trying to circumvent it. As long as there are owners, there can be problems. https://www.theregister.com/software/2025/09/25/open-source-to-closed-doors-rubygems-control-fight-erupts/1440976 is another example how it can play out. > enabling a "git-ops" style of organization/repo settings. In Forgejo Actions, I'm striving for moving things out of the Git repository into the settings. Having settings in the Git repository is a giant headache because almost everybody has write access to the repository. That makes things like `permissions` in workflows almost pointless.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sleepy/forgejo#12451

No description provided.

Rows
Columns