protected-refs-policy: the always-allowed forge is hardcoded, so a template deployment cannot push to its own forge VM #272

New issue

Closed

opened 2026-10-10 18:41:31 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-10 18:41:31 +01:00

Contributor

git-hooks/protected-refs-policy treats one public forge as the deployment's own and refuses every other remote not listed in allowed-external-remotes, so on a deployment built from the public template the dev VM cannot push to its own forge VM.

Evidence, public install walk, a template hypervisor after getting-started.sh --forge and provision-vm --replace allod-dev, 2026-10-10: git push -u origin <branch> from ~/work/allod/tools inside the VM is refused by the VM's own pre-push hook with ERROR: Push to 'ssh://git@192.168.122.12:2222/allod/tools.git' is not authorized. before the server is reached.

Cause, read from the hook: is_allowed_external_remote always allows a URL containing forge.anarch.diy and otherwise consults ~/.config/git/allowed-external-remotes, which the public secrets template ships empty. The deployment's forge is identity's forgeHost, rendered into the VM by allod/archetypes (FORGE_URL, the ssh config), but the hook has no way to read it.

Proposal: the "personal forge" the hook always allows comes from a file the dev builder renders beside the policy files, ~/.config/git/forge-host, carrying identity's forgeHost; the hook reads it and keeps the allowlist for everything else. A deployment whose identity names the public forge behaves exactly as today. Until then the template allowlist carries the forge VM's address (allod/secrets, the template's git/allowed-external-remotes).

Why the end-to-end witness in allod/archetypes (checks/forge-sync.nix) did not catch it: its client runs with no git hooks on purpose, to prove the server-side refusal on master. A second client built with the dev VM's hooks would prove the push path an operator actually has.

Part of allod/strategy#65.

`git-hooks/protected-refs-policy` treats one public forge as the deployment's own and refuses every other remote not listed in `allowed-external-remotes`, so on a deployment built from the public template the dev VM cannot push to its own forge VM. Evidence, public install walk, a template hypervisor after `getting-started.sh --forge` and `provision-vm --replace allod-dev`, 2026-10-10: `git push -u origin <branch>` from `~/work/allod/tools` inside the VM is refused by the VM's own pre-push hook with `ERROR: Push to 'ssh://git@192.168.122.12:2222/allod/tools.git' is not authorized.` before the server is reached. Cause, read from the hook: `is_allowed_external_remote` always allows a URL containing `forge.anarch.diy` and otherwise consults `~/.config/git/allowed-external-remotes`, which the public secrets template ships empty. The deployment's forge is identity's `forgeHost`, rendered into the VM by `allod/archetypes` (`FORGE_URL`, the ssh config), but the hook has no way to read it. Proposal: the "personal forge" the hook always allows comes from a file the dev builder renders beside the policy files, `~/.config/git/forge-host`, carrying identity's `forgeHost`; the hook reads it and keeps the allowlist for everything else. A deployment whose identity names the public forge behaves exactly as today. Until then the template allowlist carries the forge VM's address (allod/secrets, the template's `git/allowed-external-remotes`). Why the end-to-end witness in `allod/archetypes` (`checks/forge-sync.nix`) did not catch it: its client runs with no git hooks on purpose, to prove the server-side refusal on master. A second client built with the dev VM's hooks would prove the push path an operator actually has. Part of allod/strategy#65.

vnprc referenced this issue from a commit

2026-10-10 23:16:07 +01:00

protected-refs-policy: take the deployment's forge from forge-hosts

vnprc referenced this issue from a commit

2026-10-10 23:16:07 +01:00

extract_remote_host: fix scp-form spoof, restrict schemes to known ones

vnprc-agent commented

2026-10-11 15:53:02 +01:00

Author

Contributor

Landed on allod/tools master d3fad6d and 514f2fd (the hook reads ~/.config/git/forge-hosts), with the renderer in allod/archetypes e1f97e6 and the pin chain through the deploy template. Witnessed by the forge-sync end-to-end check with a hooked client and by the sixth clean install's branch push.

Landed on allod/tools master d3fad6d and 514f2fd (the hook reads ~/.config/git/forge-hosts), with the renderer in allod/archetypes e1f97e6 and the pin chain through the deploy template. Witnessed by the forge-sync end-to-end check with a hooked client and by the sixth clean install's branch push.

vnprc-agent closed this issue

2026-10-11 15:53:02 +01:00