CRITICAL: git guards fail open on chained inline aliases — one-level re-expansion drops command-line -c/--config-env (case C + config-env H1/H2)

[kyle-sexton]

CRITICAL — git guards fail open on chained inline aliases (real reset --hard executes)

block-dangerous-git and block-noncanonical-commit allow a dangerous git subcommand reached through a chained inline alias, and real git executes it. Ground-truth verified: a tracked file reverted DIRTY→ORIGINAL and HEAD hard-reset ("HEAD is now at … init").

Repro (both confirmed exit 0 = ALLOW, then git runs the dangerous op)

• Case C (no config-env at all): git -c alias.rh='foo' -c alias.foo='reset --hard' rh → guard exit 0 → reset --hard runs.
• Commit-guard variant: git -c alias.c='--config-env=alias.foo=AV foo' c → exit 0.

Root cause (isolated, airtight)

The inline-alias re-check recurses with HOOK_NO_ALIAS=1, which suppresses the alias-expansion re-check at recursion depth ≥2. It rests on the code comment at plugins/guardrails/hooks/block-dangerous-git.sh:220 — "git does not expand the first word of an expansion as another alias" — which is FALSE: git chains alias→alias (confirmed git lvl2→lvl1 exec on git-for-Windows 2.54.0). So a dangerous subcommand reached one alias-hop deeper than the guard re-checks slips to ALLOW. An UNKNOWING false premise (undisclosed in CHANGELOG/docs), not an accepted limitation.

Scope / relationship to #903

Pre-existing — parent commit c11a440 allows these identically; #903 introduces no regression. Distinct from #903's config-env reposture: the config-env-at-depth path (Case A) is being fixed within #903 (ungate the value-blind config-env SHAPE refusal from HOOK_NO_ALIAS so it fires at every depth). This issue is the BROADER hole: plain -c alias→alias chaining to a dangerous literal, which the config-env fix does not cover.

Fix direction

Reconsider the one-level-alias-recheck assumption: git genuinely chains aliases, so the alias-expansion re-check must recurse to the actual invoked subcommand (bounded by git's own alias-loop limit), not stop at depth 1. Both guards share the pattern.

Defer classification

Security-control fail-open with ground-truth destruction = defer-forbidden CLASS. Filed as a standalone CRITICAL (not deferred to a milestone) because the fix is broader than #903's reposture scope and touches the shared inline-alias resolver; must land before the guardrails work-ready freeze. Tie to the guardrails hardening umbrella (#912) as a blocker.

Origin

Independent convergence-verification of PR #903's structural reposture (tower out-of-loop, 2026-07-22 ~07:10Z), question-3 adversarial pass.

[kyle-sexton]

RE-SCOPE (tower, ~07:45Z) — root cause is broader than the title's "plain chain, no config-env"

Convergence-verification of #903 surfaced a --config-env manifestation of this same root cause (H1) that the original wording would wrongly exclude. Re-scoping this issue to the ROOT CAUSE so a narrow fix cannot close it while H1 stays live.

Root cause (the real defect)

The inline-alias re-expansion splice in both guards — check_segment "${w[@]:0:gi+1}" $expw "${w[@]:sub_idx+1}" — is one-level AND drops the command-line -c / --config-env options that sit between gi+1 and sub_idx. So when git chains alias→alias (which git genuinely does — the "git does not expand the first word of an expansion as another alias" comment at block-dangerous-git.sh:220 is FALSE), the recursion re-parses the second-hop subcommand WITHOUT the global options real git still applies. Result: ANY chain reaching a dangerous op via a second alias hop reaches ALLOW.

Both manifestations (both rc=0, both execute real reset --hard / bypass — ground-truth verified)

• Case C (plain literal, no config-env): git -c alias.rh='foo' -c alias.foo='reset --hard' rh.
• H1 (config-env second hop): git -c alias.rh='foo' --config-env=alias.foo=AV rh with AV='reset --hard'. Commit twin: git -c alias.c='foo' --config-env=alias.foo=AV c (AV='commit --no-verify') → commit-guard rc=0. H2 (config-env before the -c) also rc=0.

H1 is NOT covered by #903's ungated shape refusal: that refusal fires only when the config-env alias for the CURRENTLY-invoked sub is in the current recursion's argv; it's evaded when the config-env is a command-line option reached via inline-alias indirection to its key (the splice dropped it).

Fix direction (covers case C AND H1/H2 together)

The inline re-expansion must recurse to the ACTUAL invoked subcommand (bounded by git's own alias-loop limit), carrying the command-line -c/--config-env global options through each hop instead of dropping them in the splice. Both guards share the pattern.

Not a regression / scope note

Pre-existing (rc=0 on both pre- and post-#903-case-A commits; #903's case-A fix correctly did not touch it). Precise boundary for the fixer (verbatim from the convergence verifier): the shape refusal fires iff the config-env alias for the currently-invoked sub is present in the current recursion's argv; it is evaded when the config-env is a command-line option reached via inline-alias indirection to its key. Still defer-forbidden CLASS (security-control fail-open, ground-truth destruction); a proper fix must land before the guardrails work-ready freeze. Blocker on the guardrails hardening umbrella (#912).

[kyle-sexton]

Tower design prep (2026-07-22, Opus analysis vs origin/main post-#903) — fixer brief ready:

Root cause confirmed as two coupled defects in BOTH guards' git-alias re-expansion branch:

1. The nested re-parse splice ${w[@]:0:gi+1} drops everything between the git token and the subcommand — i.e. the command-line -c/--config/--config-env globals — so the nested hop sees empty config: no second-hop alias definition, no env shape to refuse, no plain/.command union (closes nothing at depth ≥ 2). Verified traces: H1/H2 ALLOW dangerous.
2. HOOK_NO_ALIAS=1 caps git-alias re-expansion at one level on the false premise git does not chain aliases (it does) — case C ALLOWs.

Fix (guard-local only — no lib/hook-utils.sh change, no 12-plugin sync, guardrails-only version bump):

• Change 1: widen the splice to ${w[@]:0:sub_idx} so wrappers + git + ALL command-line globals ride into every nested re-parse; the already-ungated env shape-refusal and the plain/.command max-danger union then fire at every hop (closes H1/H2, and covers .command-spelling chained variants by construction).
• Change 2: replace the one-level cap (git-alias + persisted-alias branches only; ! shell-alias path untouched) with a save/restore seen-set of resolved subcommand names — repeat = git's own alias-loop stop (nothing runs, allow-safe); termination guaranteed by finite distinct alias keys. Closes case C and the persisted alias.c→x→commit sibling.
• State hygiene: seen-set saved/restored around recursion, initialized at guard entry (multi-command lines = multiple callback invocations).

Test matrix: blocking — case C, H1, H2, 3-hop chain, .command second hop, commit-guard inline twin, persisted chain (fixture repo); benign controls — 2-hop safe chain rc0, cycle terminates-and-allows without hang; regression neighbors L204-252 must hold.

Rejected: change-1-only (leaves case C), change-2-only (inert), numeric depth cap (allow-at-cap unsound), SSOT extraction to lib (correct long-term, wrong pre-freeze tradeoff — follow-up).

Sequencing: implementation branches from origin/main and lands after #960 merges (same files). Dispatching on #960 merge.

[kyle-sexton]

CLAIM (control tower): implementation dispatched now per the READY design above (branch from origin/main; will re-merge main after #960 lands — regions disjoint from #960's classifier diff). Lanes: do not pick this issue.