fix(gitea): admins could override the gate #10

2026-09-29T07:38:11Z

gitea-admin commented

2026-09-29 07:38:11 +00:00

The enforcement we turned on earlier today was not enforcing.

enable_status_check: true and required_approvals: 1 were set and recorded as done. They did
not bite. block_admin_merge_override was false, and Gitea lets repository admins override
merge requirements without it. jakman85 holds owner — so both requirements were bypassable by
exactly the account that performs every merge.

The evidence was already on the record:

PR #5 reviews: []   #6: []   #7: []   #8: []   #9: []

All five merged with required_approvals: 1 in force and zero approvals on any of them.

Two process failures, both the shape of the original defect

Verified with the wrong view. /branches/main reports protected, enable_status_check
and required_approvals — but not block_admin_merge_override. It showed all green while
the rule was overridable. /branch_protections/main is authoritative.
Probed for a field name I assumed existed. This Gitea (1.24.3) has no apply_to_admins.
Asking jq for it returns null — which reads exactly like "set to false" but means "key
absent" — so a PATCH that silently did nothing produced a convincing before/after.
jq returning null is not a value; it may be an absence. Enumerate with to_entries.

Changes

require-gate.sh now sets block_admin_merge_override: true; block-admin-override.sh fixes it
in isolation. Both carry the field-name warning. infra/gitea/README.md gains step 5.

⚠️ This PR is the test

The setting is applied and read back as true, but that is a setting, not evidence. If this
PR merges without an approval, the fix did not work and the finding stands. Let the gate go
green, then try to merge it without approving — Gitea must refuse.

A decision for you, not a default I should pick

Two accounts exist: jakman85 (human, owner) and gitea-admin (agent). With approvals genuinely
required, an agent-authored PR gets approved by you — the intent. But a PR you author now needs
gitea-admin to approve it: the automation account rubber-stamping the human. That's ceremony,
not review. Keep it, drop required_approvals to 0 and rely on the status check (which actually
verifies something), or add a second human.

Gate: PASS, rc 0, 76s.

Co-Authored-By: Claude Opus 5 (1M context) [email protected]

🤖 Generated with Claude Code

**The enforcement we turned on earlier today was not enforcing.** `enable_status_check: true` and `required_approvals: 1` were set and recorded as done. They did not bite. **`block_admin_merge_override` was `false`**, and Gitea lets repository admins override merge requirements without it. `jakman85` holds `owner` — so both requirements were bypassable by exactly the account that performs every merge. The evidence was already on the record: ``` PR #5 reviews: [] #6: [] #7: [] #8: [] #9: [] ``` All five merged with `required_approvals: 1` in force and **zero approvals on any of them.** ### Two process failures, both the shape of the original defect 1. **Verified with the wrong view.** `/branches/main` reports `protected`, `enable_status_check` and `required_approvals` — but *not* `block_admin_merge_override`. It showed all green while the rule was overridable. `/branch_protections/main` is authoritative. 2. **Probed for a field name I assumed existed.** This Gitea (1.24.3) has no `apply_to_admins`. Asking `jq` for it returns `null` — which reads exactly like "set to false" but means **"key absent"** — so a PATCH that silently did nothing produced a convincing before/after. **`jq` returning null is not a value; it may be an absence.** Enumerate with `to_entries`. ### Changes `require-gate.sh` now sets `block_admin_merge_override: true`; `block-admin-override.sh` fixes it in isolation. Both carry the field-name warning. `infra/gitea/README.md` gains step 5. ### ⚠️ This PR is the test The setting is applied and read back as `true`, but **that is a setting, not evidence.** If this PR merges **without an approval**, the fix did not work and the finding stands. Let the gate go green, then try to merge it without approving — Gitea must refuse. ### A decision for you, not a default I should pick Two accounts exist: `jakman85` (human, owner) and `gitea-admin` (agent). With approvals genuinely required, an agent-authored PR gets approved by you — the intent. But a PR *you* author now needs `gitea-admin` to approve it: the automation account rubber-stamping the human. That's ceremony, not review. Keep it, drop `required_approvals` to 0 and rely on the status check (which actually verifies something), or add a second human. Gate: **PASS, rc 0, 76s**. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gitea-admin added 1 commit 2026-09-29 07:38:11 +00:00

fix(gitea): admins could override the gate -- the enforcement was not enforcing

gate / gate (pull_request) Successful in 1m34s

Details

gate / conformance (pull_request) Has been skipped

Details

fcc66c7858

enable_status_check and required_approvals were set earlier today and recorded as done.
They did not bite. block_admin_merge_override was false, and Gitea lets repo admins
override merge requirements without it. jakman85 holds owner, so both requirements were
bypassable by exactly the account that performs every merge.

The evidence was already on the record: PRs #5-#9 all merged while required_approvals: 1
was in force, with ZERO approvals recorded on any of them.

Two process failures, both the same shape as the defect this whole session started with:

1. Verified with the wrong view. /branches/main reports protected, enable_status_check and
   required_approvals but NOT block_admin_merge_override -- it showed everything green while
   the rule was overridable. /branch_protections/main is authoritative.
2. Probed for a field name assumed to exist. This Gitea (1.24.3) has no `apply_to_admins`;
   asking jq for it returns null, which reads like "set to false" but means "key absent", so
   a PATCH that silently did nothing produced a convincing before/after. jq returning null
   is not a value -- it may be an absence. Enumerate with to_entries.

require-gate.sh now sets block_admin_merge_override: true; block-admin-override.sh fixes it
in isolation. Both carry the field-name warning.

This PR is the test. If it merges WITHOUT an approval, the fix did not work.

Also records the governance question: with only jakman85 (human) and gitea-admin (agent),
a human-authored PR now needs the automation account to approve it. That is ceremony, not
review, and the choice between keeping it, dropping approvals in favour of the status
check, or adding a second human is the operator's to make.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

jakman85 approved these changes

2026-09-29 07:43:46 +00:00

jakman85 merged commit e8e6b9c681 into main

2026-09-29 07:43:53 +00:00

jakman85 referenced this issue from a commit

2026-09-29 07:43:54 +00:00

Merge pull request 'fix(gitea): admins could override the gate' (#10) from fix/gitea-admins-could-override-the-gate into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Home-Network/home-network-k3s-impl#10