guardrails: env -u / env -i prefixes false-positive under value-blind config-env shape guard (over-block, fail-safe)

[kyle-sexton]

Split from PR #903 review thread (lib/hook-utils.sh:694 discussion). Under the value-blind reposture, a command like env -u AV git --config-env=alias.rh=AV rh or env -i ... is shape-blocked even though the unset/cleared env var means the alias cannot resolve — a false positive.

Direction: OVER-block (fail-SAFE) — the guard refuses something harmless; it never lets something dangerous through. Deferrable per the defer-forbidden direction test (operating-procedures: under-counting/over-blocking is fail-safe).

Post-reposture the over-block persists by design (the guard deliberately never reads env values), so the fix space is narrow: either model env -u/-i prefixes as a shape-level exception, or document as an accepted limitation of value-blindness. Origin: PR #903 review finding (reviewer identified the pre-reposture ambient-lookup mechanism; the reposture changed the mechanism but preserved the over-block).

Repro: with guardrails active, env -u AV git --config-env=alias.rh=AV status style invocations refuse despite AV being unset.

[kyle-sexton]

This was generated by AI during triage.

Problem

Under PR #903's value-blind reposture, env -u AV git --config-env=alias.rh=AV rh (or env -i …) is shape-refused even though the unset/cleared AV means git could never resolve the alias — a fail-safe over-block. The fix space is narrow: (a) model env -u/env -i as a shape-level exception, or (b) accept it as a documented limitation of value-blindness.

What the code does today

Post-#903 (commit deleting the resolver: "refuse --config-env guarded-subcommand aliases by shape, delete resolver"), the classification lives in hook::git_alias_expansion: for the invoked subcommand, if the last matching alias.<sub>= entry was collected from --config-env (kind env, tagged in hook::git_resolve_subcommand), it returns a block by shape — the environment variable's value is deliberately never read. hook::git_resolve_index already walks past env-prefix operands and options (including -u NAME and -i) purely to locate the git token; it captures none of their effect on the environment. So the over-block is structural: the guard has no channel by which env -u AV could inform the decision, by design.

Recommendation — (b) accept as a documented limitation

Two independent pillars, both empirically checked against git 2.54.0.windows.1:

1. Zero functional harm. git itself fatals on an unset --config-env variable — verified: env -u AV git --config-env=alias.st=AV st → fatal: missing environment variable 'AV', exit 128. The over-blocked command was already non-functional; the guard's refusal only changes the error text on a command that could never run. No legitimate workflow is blocked.

2. The carve-out cannot be had cheaply without regressing the reposture. A general "an env -u/env -i is present ⇒ treat the config-env alias as safe" rule is fail-open — verified: env -u AV AV='reset --hard' … and env -i AV='reset --hard' … both re-set AV (an operand assignment after -u/-i wins), and nested env, bash -c export, or set -a multiply the vectors. Only a narrow form (env -u AV directly wrapping git, no AV= operand, no interposed shell/wrapper) is genuinely shape-decidable and safe — but honoring even that reintroduces environment-manipulation reasoning into a guard whose entire design value, per the reposture, is being blind to it. That is precisely the surface the reposture spent ~225 deleted lines closing ("each attempt to resolve it has reopened a fail-open"), traded for making a broken command fail with a different message. Not worth the attack surface.

Security-adversarial concern (explicit)

The fail-open form of the naive carve-out — env -u AV AV='reset --hard' git --config-env=alias.rh=AV rh slipping through because the guard saw the -u AV but not the re-set — is structurally the same bypass class as #964: the guard trusting a surface the attacker re-supplies at a level the guard did not fully track. Adding an env-unset carve-out is an invitation to reopen exactly that class. The value-blind shape refusal is the correct posture.

Concretely for (b): add a short note to the guardrails changelog / hook header recording that env -u/env -i in front of a --config-env-defined alias for the invoked subcommand is over-blocked (fail-safe) by design, and close this issue as an accepted limitation.

Decision defaulted: accept as documented limitation of value-blindness (option b) — veto before merge

[kyle-sexton]

Closing as an accepted limitation (fail-safe over-block), per the issue's own direction.

Evidence: Under the value-blind --config-env shape guard, env -u / env -i prefixes are refused even when the env var is unset/cleared. This is deliberate: the guard never reads env values, so it cannot prove the alias is inert.

• Issue body: "OVER-block (fail-SAFE) … document as an accepted limitation of value-blindness"
• Tests document the env -u -C non-chdir shape in block-noncanonical-commit.test.sh / block-dangerous-git.test.sh

No fail-open path remains; the residual is cosmetic over-refusal only.