guardrails: block-dangerous-git resolves lease hash-width for the wrong repository across a `!` alias hop

[kyle-sexton]

Problem

repo_oid_width() in plugins/guardrails/hooks/block-dangerous-git.sh determines the repository's object-id width — which decides whether a --force-with-lease=<ref>:<expect> expectation is an immutable full-width object id or a movable ref name — by probing with the hook process's own cwd plus the segment's replayed locating options:

case "$(git "$@" rev-parse --show-object-format 2>/dev/null) in

That never composes a directory across a ! shell-alias reparse boundary. When an alias body re-invokes git against a different repository, the width is still resolved for the original one. If the two repositories use different hash formats, a lease expectation is judged against the wrong width.

This is the same structural miss that #1085 fixed in block-noncanonical-commit: the guard resolved a directory per segment and never propagated where a ! body actually runs. That guard now asks git (git -C <dir> rev-parse --show-toplevel) and composes the answer across hops; block-dangerous-git still does not.

Exploit shape

Narrow — it needs all of:

1. A ! shell alias (inline -c alias.x='!git …' or persisted) whose body invokes git against a different repository than the outer command.
2. That target repository using the other hash format (SHA-256 when the outer is SHA-1, or vice versa).
3. A git push --force-with-lease=<refname>:<expect> in the body where <expect> is a full-width hex string for the outer repo's format — so it reads as an immutable object id there — that is also a valid ref name in the target repository.

Condition 3 is the same residual the file already documents for the --force-with-lease width check: a hex-named ref of the other width is an ordinary movable ref name, so the lease passes while clobbering work the pusher never saw.

Why it was deferred out of #1085

Recorded per the maintainer's call on that PR. Closing it means replicating the effective-base machinery (HOOK_EFFECTIVE_BASE propagation plus a git-resolved identity primitive) into a guard that otherwise resolves no paths at all — block-dangerous-git has no persisted-config lookup, no HOOK_CWD read, and no shell-alias seen-set. That is real scope growth, and #1085 was four review rounds deep on a merge-blocking branch.

Sibling residual already documented

block-dangerous-git.sh documents a related gap in the same family at the lease_expect_is_immutable / repo_oid_width comments:

Known gap: a compound cd <elsewhere> && git push … pushes from a directory no option names, so the probe cannot see it. Resolving the cd target would mean evaluating arbitrary shell word expansion, which this guard deliberately does not do.

Both are "the guard cannot see which repository the push will run in". A fix should consider them together rather than patching the ! case alone — otherwise this is a third round of the same class in a different guard.

Fix direction

Adopt the mechanism block-noncanonical-commit now uses, rather than inventing a second one:

• Ask git for the directory instead of modelling it. Do not normalize paths lexically, and do not resolve them with a shell primitive — verified on git 2.54.0.windows.1 that cd -P link/.. and git -C link/.. disagree, because Win32 normalizes .. textually while POSIX resolves it through the kernel.
• Propagate the resolved repository across each ! reparse (git runs a shell body from the repository top level), and key the width cache on that resolved identity rather than on the replayed option list alone.
• Fail closed when git cannot resolve the target — consistent with repo_oid_width's existing 0 means undeterminable → fails closed posture.

Verification shape

A fixture pairing a SHA-1 repository with a SHA-256 one, a ! alias crossing between them, and a lease pinned to a 40-hex string that is also a tag name in the SHA-256 repo. block-dangerous-git.test.sh already builds both REPO_SHA1 and REPO_SHA256 fixtures, so the scaffolding exists.

[kyle-sexton]

This was generated by AI during triage.

Triage: verified — human-gated

Core defect: confirmed real. Traced the failure path in block-dangerous-git.sh:

• The ! shell-alias re-check recurses via hook::bash_parse_segments on the reparsed alias body, calling check_segment again on the inner git invocation. That recursion propagates no directory context from the outer segment — it only re-derives collect_git_locating_opts from the inner segment's own literal words.
• repo_oid_width()'s cache key is "$*" of git_locating_opts alone. When the alias body's own git invocation carries no explicit -C/--git-dir (the common shell-alias shape), the probe runs with an empty option list — i.e. against whatever repository the hook process's own cwd happens to be — not against the repository the outer segment actually resolved to (e.g. via the outer's own -C).
• Downstream, lease_expect_is_immutable feeding a wrong width means a hex --force-with-lease=<ref>:<expect> that is actually a movable ref name in the real target repo can be misjudged as an immutable object id. lease_movable then never gets set, the push-lease-unsafe block at that call site never fires, and the push proceeds. Confirmed fail-open direction — this is a guard bypass, not an over-block.
• Test-gap check: block-dangerous-git.test.sh covers direct cross-repo cases via explicit -C/--git-dir (REPO_SHA1/REPO_SHA256 fixtures, e.g. the git -C <sha256-repo> push --force-with-lease=... cases). No case exercises a ! alias hop crossing hash formats. The issue's claim that this scaffolding exists is accurate.

Correction to the issue body — the cited prior art does not exist. Verified against the actual repo state, not the issue's description of it:

• #1085 ("fix(guardrails): close git-alias-chain re-expansion bypass of both git guards") is currently OPEN, unmerged. Its diff is unrelated to directory resolution: it widens the recursive splice from ${w[@]:0:gi+1} to ${w[@]:0:sub_idx} so command-line globals ride into nested alias hops, and replaces a one-level recursion cap with a HOOK_ALIAS_SEEN set to support alias chaining depth. Neither change touches where a probe resolves its target repository.
• block-noncanonical-commit.sh has never contained git -C <dir> rev-parse --show-toplevel at any point in its git history. Its actual mechanism, effective_dir(), string-composes relative -C values onto HOOK_CWD (the hook payload's cwd) — it does not ask git to resolve anything, and it does not propagate across a ! alias reparse boundary either: the recursive check_segment call for an alias body's shell command does not pass forward a resolved base directory, so a bare (no--C) inner git invocation would face the same class of gap effective_dir exists to close.
• Net: the "Fix direction" section prescribes adopting a mechanism that doesn't exist in this codebase. An implementer (agent or human) taking that section at face value would either copy effective_dir and ship a fix that still doesn't compose across the alias hop, or stall looking for code that isn't there.

Why human-gated, not autonomous-eligible. The underlying vulnerability is real and narrow (requires a ! alias whose body targets a different-hash-format repository, plus a lease hex string that collides with a valid ref name there). Closing it means designing a directory-propagation primitive from scratch for a guard that currently resolves no paths at all (no HOOK_CWD read, no persisted-config lookup, no alias-seen-set for directory purposes) — there is no existing mechanism in this repo to point an agent at, contrary to the issue's own fix-direction section. That's a design decision, not brief execution, especially combined with the Windows path-normalization divergence the reporter already flagged (cd -P link/.. vs git -C link/.. disagreeing on git 2.54.0.windows.1). The documented compound-cd residual is explicitly out of scope already ("evaluating arbitrary shell word expansion, which this guard deliberately does not do"), so that part is not an open fork — only the propagation-primitive design is.

Priority: priority: high (above the assessed default priority: medium) — a safety guard silently failing open on force-with-lease protection is significant impact even though the trigger preconditions are narrow (specific alias shape + cross-hash-format repo + hex/ref-name collision), not an active/observed exploit, so not critical.

Role-label note: .work-item-tracker.json has no config.role_labels entry, so the canonical human-gated role resolves to its documented default (needs-human) — flagging per the role-label resolution invariant in case this repo ever remaps roles.

Outcome: labels normalized off priority: needs-triage; applying priority: high + needs-human. area: security retained. Type was already native Bug.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave.

repo_oid_width() alias-hop mis-resolution is the same compound-shell / wrong-repository class as #1500 (carrier) and the guardrails hardening umbrella #912. Recorded here for history; one coordinated alias-reparse fix should address block-dangerous-git and block-noncanonical-commit together.

Re-open trigger: Alias reparse lands on main with cross-repo width/alias tests.