Remove ALLOW_PROTECTED_REF bypass from hook policy #62

New issue

Closed

opened 2026-06-23 00:03:19 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-06-23 00:03:19 +01:00

Contributor

Problem

ALLOW_PROTECTED_REF=1 is a legacy escape hatch in protected-refs-policy. It began as an early attempt to avoid teaching agents to use --no-verify, but it is now the wrong abstraction: the new allod change workflow should be the safe interface, and the Git hook should remain a backstop rather than expose a broad blessed bypass.

The variable is currently too broad. It bypasses protected-branch checks, signing-required checks, unauthorized remote checks, and force-push checks on agent/* / active PR branches. That weakens the controls added for parking-lot#35 if an agent learns to use it.

Scope

Remove the bypass and every mention of it from:

allod/tools/protected-refs-policy
allod/tools/tests/protected-refs-policy.sh
vnprc/secrets docs and validation text that mention ALLOW_PROTECTED_REF
parking-lot plans/docs that still describe it as future cleanup, if they are still current enough to update

Acceptance criteria

ALLOW_PROTECTED_REF no longer appears in active code or docs under the Allod repos.
Protected branch, signing, unauthorized remote, and force-push checks cannot be bypassed through this bespoke environment variable.
Tests cover the remaining expected behavior without override cases.
If a human truly needs to bypass a local hook, the docs point to standard Git mechanisms and make clear that this is an intentional human action, not agent workflow.

Rationale

allod change should own normal code-change workflow: protected-repo isolation, additive commits, safe pushes, and PR handoff. Hooks should provide early feedback/backstop enforcement. Forgejo branch protection remains the final guard. A broad custom bypass does not fit that model.

## Problem `ALLOW_PROTECTED_REF=1` is a legacy escape hatch in `protected-refs-policy`. It began as an early attempt to avoid teaching agents to use `--no-verify`, but it is now the wrong abstraction: the new `allod change` workflow should be the safe interface, and the Git hook should remain a backstop rather than expose a broad blessed bypass. The variable is currently too broad. It bypasses protected-branch checks, signing-required checks, unauthorized remote checks, and force-push checks on `agent/*` / active PR branches. That weakens the controls added for parking-lot#35 if an agent learns to use it. ## Scope Remove the bypass and every mention of it from: - `allod/tools/protected-refs-policy` - `allod/tools/tests/protected-refs-policy.sh` - `vnprc/secrets` docs and validation text that mention `ALLOW_PROTECTED_REF` - parking-lot plans/docs that still describe it as future cleanup, if they are still current enough to update ## Acceptance criteria - `ALLOW_PROTECTED_REF` no longer appears in active code or docs under the Allod repos. - Protected branch, signing, unauthorized remote, and force-push checks cannot be bypassed through this bespoke environment variable. - Tests cover the remaining expected behavior without override cases. - If a human truly needs to bypass a local hook, the docs point to standard Git mechanisms and make clear that this is an intentional human action, not agent workflow. ## Rationale `allod change` should own normal code-change workflow: protected-repo isolation, additive commits, safe pushes, and PR handoff. Hooks should provide early feedback/backstop enforcement. Forgejo branch protection remains the final guard. A broad custom bypass does not fit that model.