fix(ci): resolve what a command actually executes before matching it in the publication-order guard

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

Two P1s raised by Codex against #2848 at head d6401f9c, both confirmed. They are one family:
the guard resolves a command by the word written, not by what bash will actually execute.

1. hash -p rebinds a required tool. A signing block can run
hash -p /usr/bin/true cosign before an otherwise valid
cosign sign --yes --recursive "${REF}". Bash's help hash documents -p pathname as using that
pathname for the named command, so the "signing" call executes true, returns success, and
reconciliation proceeds with no signature published. The alias vector is already hardened here;
the command hash table is the same bypass through a different mechanism and is currently untracked.

2. An interpreter-wrapped workload operation is invisible. If a step invokes the wrapper as
bash ./scripts/run-ksail-prod-with-pull-auth.sh workload push, bash runs that script with those
arguments, but the matcher reads the executable as bash and omits the operation entirely. An
existing direct push then satisfies the pre-evidence marker while a second, interpreter-wrapped
push of modified manifests happens after signing and attestation — and the recognised reconcile
releases it. That is the ordering guarantee inverted while every check passes.

Why these two together

Both are "the token in the source is not the operation that runs". Fixing them separately would
restate the same missing predicate twice, exactly as the four value-assertion findings in #2870 do one
level up. The natural shape is a single command-resolution step used by every matcher: resolve what a
command word will actually execute (rejecting rebinding of a required tool) and unwrap known
interpreters (bash/sh + script path) before matching an operation.

Scope note

#2848 closes the ordering axis, the two shell-parsing bypasses, and (at 7376dfba) nameref aliasing
of a protected variable. This is the command-resolution axis and is tracked here rather than
extending a PR already well past a dozen review rounds. Sibling: #2870 (value assertions).

Acceptance criteria

• Rebinding a required executable via the command hash table is rejected, with a test using
  hash -p before the signing call.
• A workload operation invoked as bash <script> workload <op> (and sh) is recognised as that
  operation, with a test proving a post-evidence interpreter-wrapped push is caught.
• One shared command-resolution helper, rather than a check per matcher.
• Over-tightening controls: .github/actions/deploy-prod/action.yml still validates clean, and a
  legitimate bash -c that is not a workload operation is not misread as one.
• Each rejection test proven to fail when its own assertion is removed.

Size: medium — one resolution helper, matcher call sites, and their tests.

Part of #2627. Raised on #2848.

[coderabbitai]

🔗 Related PRs

#2404 - fix: tenant artifact verification rejects the dual signing identities from #2399 [merged]
#2625 - fix(deploy): synchronize production GHCR pull auth [merged]
#2633 - fix(deploy): verify incoming image on Talos nodes [merged]
#2635 - fix(deploy): reboot stale nodes so containerd adopts refreshed GHCR auth [merged]
#2816 - fix(security): reject floating workflow refs in cosign subject matchers [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Agentic Engineer

Three more vectors in this family, and an argument for one rule instead of three

Codex raised these against #2848 at e2749af3 on 2026-08-01. All three let a syntactically valid,
errexit-covered cosign sign produce no signature:

vector	why the guard credits it
BASH_ENV: ./setup.sh in the step env	bash sources that file before the script, so cosign() { true; } defined there wins — and the guard never reads it
trap '…; exit 0' ERR	the handler runs where -e would exit and exits 0, so a failed signature leaves the step green
set -n before the call	noexec reads without executing; the guard keeps crediting later commands

These are not three more shapes to model. main.go already records the lesson — enumerating
shapes one at a time "is a blocklist, and the list never ended", and asking the parser what runs is
the allowlist equivalent. But BASH_ENV, traps and noexec are not grammar; they are environment and
runtime effects that change what a valid call does, so the parser cannot answer for them.

The stance that fits the existing design is the one litOK already takes for a non-static word:
refuse to certify rather than guess. A step carrying any of these is unmodelable, so the guard
should fail closed on it instead of proving an ordering it cannot actually see. That is one rule
covering all three, and it stays closed against the next construct in the family — which matters,
because this is now the second round of vectors on the same PR.

Worth deciding here whether that fail-closed rule supersedes the per-vector modelling this issue
currently describes for hash -p; those two are resolvable by the parser, so they may still warrant
real resolution rather than refusal.

[devantler]

🤖 Generated by the Agentic Engineer

Third instance of the same missing predicate: env-wrapped operations

Raised by Codex against #2848 at 57d69088, confirmed by reading scriptTarget.

scriptTarget strips command/builtin prefixes through commandStart and unwraps the
interpreters set (bash, sh, dash, ksh, zsh). env is in neither, so:

env ./scripts/run-ksail-prod-with-pull-auth.sh workload push

returns exec = "env", viaKsail("env") is false, and the workload push is omitted entirely. An
existing direct push still satisfies the pre-evidence marker while this one republishes the mutable
tag after the attestations — the ordering guarantee inverted while every check passes. Same
outcome as instance 2, reached through a different wrapper.

Why this makes the enumeration argument concrete

env is not special. nohup, timeout, stdbuf, nice, ionice, setsid, xargs, sudo,
doas, time, flock, chroot and unshare all place the real operation somewhere after argv[0].
Adding them one at a time is a review round each, and the predicate stays wrong between rounds.

Codex named the alternative directly: unwrap the wrapper, or reject unclassified command
wrappers. The second is the fail-closed form and is the one consistent with the inversion this
file already applied on its shell-state axis — accept only what has been reasoned about, and error
naming the construct when something else appears.

Deliberately not patched in #2848: adding env there buys one round and leaves this issue open
anyway.

[devantler]

🤖 Generated by the Agentic Engineer

Third instance, and the clearest statement of the underlying problem so far — surfaced by Codex
on #2848 at head 79c20814, deferred here rather than patched.

Shape: a post-evidence step runs set +e, performs another ksail workload push, then set -e.
Bash executes that push. parseExecuted drops every command while errexit is off, which is
correct for deciding whether a required operation gates its step — a push whose failure cannot
fail the step must not satisfy the marker — and unsound for enumerating forbidden extra
publications, where the question is only whether it ran. The earlier push still satisfies the
marker, the hidden one moves the mutable tag after all evidence exists, and the recognised reconcile
then releases uncovered bytes.

This is the same two-scans conclusion this issue already records, reached from a third direction:

Question	Correct basis	Wrong answer if you use the other
Does a required operation gate its step?	provably runs — top-level, errexit tracked	a nested/unguarded push wrongly satisfies the marker
Is there a forbidden extra publication?	might run — any depth, errexit irrelevant	a push under set +e is invisible

Prior instances were about reach (env ./script workload push, and the wrapper family
nohup/timeout/stdbuf/nice/setsid/xargs/sudo). This one is about failure mode. They
converge on the same fix, which is why widening the single scan keeps being wrong in one direction
whichever depth or state it picks — and why enumerating wrappers buys exactly one round each.

Not attempted on #2848: that PR already carries 56 threads, and splitting one traversal into two is
a structural change that deserves its own reviewable diff. #2848's body now names this as a known
gap, so the guard ships with the boundary stated rather than implied.

[devantler]

🤖 Generated by the Agentic Engineer

Fourth instance, from platform#2848's round-7 Codex review at b8267265 (2026-08-01T20:26Z).

exec ./scripts/run-ksail-prod-with-pull-auth.sh workload push (main.go:193). Distinct from the
exec -c fix at 79c20814: that corrected the terminating direction — an unreadable word must
return false so the scan keeps looking. This is the classifying direction: exec replaces the shell
and runs a publication the scan never appends, so a second push is invisible while the earlier one
still satisfies the marker.

exec joins env, and shares the shape with nohup / timeout / stdbuf / nice / setsid /
xargs / sudo. Enumerating one buys exactly one review round each, which is why it is recorded here
rather than patched — the sound fix remains this issue's content: two traversals, provably runs
(top-level, errexit tracked) for the satisfying question and might run (any depth) for the
forbidding question. One traversal is unsound in one direction whichever depth it picks.

[devantler]

🤖 Generated by the Agentic Engineer

Closing as superseded by #2859.

This issue records a defect in the static publication-order parser built on #2848. That PR is now
closed: #2736 replaced the architecture it modelled (87 of its 117 tests encoded the previous shape),
and a pure extraction refactor silently defeated it — a fifth member of the same bypass family this
issue belongs to.

The defect described here is real, but it exists only in code that will not merge. Fixing it would
extend a parser whose bypass surface is unbounded by construction. #2859 replaces the approach:
verifying that the signature and attestations actually reached the registry before Flux is told to
look ends this entire family at once, because every bypass in it terminates in the same observable
state — no evidence attached to the digest latest names.

Reopen if a static workflow-text check is revived; the analysis here would apply again.