mcp-beaver exposes a remote_mirror ref, so `git ls-remote <repo> main` answers with two refs #963

New issue

Open

opened 2026-08-27 08:50:24 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-27 08:50:24 +00:00

Owner

Split out of coilyco-bridge/deploy#811 so it is not lost when that incident closes.

What is there

coilyco-flight-deck/mcp-beaver carries a Forgejo mirror ref in its public ref
namespace alongside the real branch:

$ git ls-remote https://forgejo.coilysiren.me/coilyco-flight-deck/mcp-beaver.git main
eebbe24e40c0369c53492dd77eab118ab83e3d4b	refs/heads/main
eebbe24e40c0369c53492dd77eab118ab83e3d4b	refs/remotes/remote_mirror_7E8Ns8IzHxT/main

Spot-checked upstreams that do not have it: coilyco-flight-deck/agent-proxy,
coilyco-flight-deck/node-stats-mcp, coilyco-gaming/sirens-echo,
coilysiren/website all answer with one ref. So this looks specific to
mcp-beaver rather than instance-wide, but nothing broader has been swept.

Why it mattered

git ls-remote <repo> main matches every ref whose last component is main, so
the second ref doubled the answer. deploy's pin reconciler piped that through
cut -f1 and got a two-line sha, which bumped every mcp-beaver pin on a
five-minute loop, appended 850 bare sha lines across 25 values files, left them
invalid YAML, and held every service CD off for about three hours.

Current state

deploy#812 hardened the consumer: the reconciler now asks for refs/heads/main
by its full name and refuses to resolve when more than one ref answers. So this
ref is no longer load-bearing for deploy, and this is not urgent.

What is not done

The ref itself is untouched. Removing it is a mutation on a shared forge's ref
namespace and was deliberately left out of the incident recovery.
Why it exists is not established: whether mcp-beaver is or was a mirror target,
and whether the Forgejo mirror configuration will recreate the ref.
No sweep has been run across the rest of the instance for the same pattern.
Nothing else that reads mcp-beaver's refs by shorthand has been audited.
git ls-remote <repo> <shorthand> is the pattern to grep for.

Split out of coilyco-bridge/deploy#811 so it is not lost when that incident closes. ## What is there `coilyco-flight-deck/mcp-beaver` carries a Forgejo mirror ref in its public ref namespace alongside the real branch: ``` $ git ls-remote https://forgejo.coilysiren.me/coilyco-flight-deck/mcp-beaver.git main eebbe24e40c0369c53492dd77eab118ab83e3d4b refs/heads/main eebbe24e40c0369c53492dd77eab118ab83e3d4b refs/remotes/remote_mirror_7E8Ns8IzHxT/main ``` Spot-checked upstreams that do not have it: `coilyco-flight-deck/agent-proxy`, `coilyco-flight-deck/node-stats-mcp`, `coilyco-gaming/sirens-echo`, `coilysiren/website` all answer with one ref. So this looks specific to mcp-beaver rather than instance-wide, but nothing broader has been swept. ## Why it mattered `git ls-remote <repo> main` matches every ref whose last component is `main`, so the second ref doubled the answer. deploy's pin reconciler piped that through `cut -f1` and got a two-line sha, which bumped every mcp-beaver pin on a five-minute loop, appended 850 bare sha lines across 25 values files, left them invalid YAML, and held every service CD off for about three hours. ## Current state deploy#812 hardened the consumer: the reconciler now asks for `refs/heads/main` by its full name and refuses to resolve when more than one ref answers. So this ref is no longer load-bearing for deploy, and this is not urgent. ## What is not done * The ref itself is untouched. Removing it is a mutation on a shared forge's ref namespace and was deliberately left out of the incident recovery. * Why it exists is not established: whether mcp-beaver is or was a mirror target, and whether the Forgejo mirror configuration will recreate the ref. * No sweep has been run across the rest of the instance for the same pattern. * Nothing else that reads mcp-beaver's refs by shorthand has been audited. `git ls-remote <repo> <shorthand>` is the pattern to grep for.