fix(install.ps1): verify-blob must not inherit a stale exit code

[LukasWodka]

Summary

$LASTEXITCODE persists from the previous command. Test-CosignRuns runs
cosign version immediately before verification and presets 255 precisely so a
binary that never starts cannot leave a stale 0 behind.

The verify-blob call that actually gates the install had no such preset.

So a cosign shim that exits 0 on version and then no-ops on verify-blob leaves
$LASTEXITCODE at 0, the -ne 0 gate reads that as success, and the installer
prints "cosign signature valid" and installs a binary nothing verified. RFC-0001
R8 defeated by a stale variable, one line from the guard that already exists.

Reproduced before fixing

Driving the real block extracted from install.ps1 under pwsh, with a verifier
that no-ops:

with fix     -> REFUSED               (LASTEXITCODE=255)
without fix  -> INSTALLED-UNVERIFIED  (LASTEXITCODE=0)

Type

fix

Test plan

Case 19 in install-verify.sh asserts the preset sits inside the
$sigDownloaded block and before the invocation, by line number — so a preset
elsewhere in the file cannot satisfy it.

Mutation-proved: removing the preset reddens case 19 with a message naming the
consequence. 34 passed / 0 failed; under mutation 33 / 1.

A limitation worth stating rather than hiding

This is a source assertion. install.ps1 has no behavioural coverage —
there is no pwsh or Pester anywhere in this repo's CI, which is why a signature
gate that does not gate reached a promotion PR. This closes the specific hole; it
does not make the Windows installer tested. That deserves its own ticket.

One self-inflicted detail, recorded because it is this repo's own failure class

The first version of the check grepped for verify-blob and matched the
explanatory comment written directly above the call, so it failed on correct
code. Anchored on the & $cosign invocation instead — prose is not wiring.

Provenance

Found by Bugbot on release-train promotion PR #528 (High). Per the staging-hop
policy, fixed on develop. Unblocks the cli leg.

Checklist

• Targets develop
• Tests added and mutation-proved
• No secrets or customer data

---

Note

High Risk
Changes mandatory cosign verification on the Windows installer; a stale exit code could install binaries that were never signature-checked.

Overview
Fixes a Windows installer signature bypass where cosign verify-blob could be treated as successful without actually running.

Test-CosignRuns already sets $global:LASTEXITCODE = 255 before cosign version so a no-op shim cannot leave a stale 0. The verify-blob call that gates installation did not do the same. After a successful version, a shim that no-ops on verify-blob left $LASTEXITCODE at 0, so the installer could report a valid cosign signature and install an unverified binary (RFC-0001 R8 / cli#528).

The PR adds the same 255 preset immediately before & $cosign verify-blob inside the $sigDownloaded block.

Case 19 in install-verify.sh asserts that preset sits between if ($sigDownloaded) and the & $cosign verify-blob invocation (line-order check; anchors on the invocation, not comment text). This is source-only coverage—there is still no pwsh/Pester behavioral test for install.ps1.

^{Reviewed by Cursor Bugbot for commit 372e868. Bugbot is set up for automated code reviews on this repo. Configure here.}

[shujaatTracebloc]

The one-line fix in install.ps1 is right and the reasoning behind it is sound — $global:LASTEXITCODE = 255 before the verify-blob invocation is exactly the guard Test-CosignRuns already carries, and install.sh never had the hole because it branches on the command directly (if "$COSIGN_BIN" verify-blob ... then). No objection to the production change.

The problem is case 19, the part of this PR that is supposed to keep the hole closed. I ran it on this branch (34/0) and then mutated it, and it does not hold: commenting the preset out leaves case 19 green, and a whitespace variant of the same correct statement turns it red. Two comments inline, both on the same fragile text match; one suggestion fixes both.

[shujaatTracebloc]

Both findings fixed, and I reproduced all three directions on 372e868 rather than taking the commit message's numbers on trust:

M1  preset commented out   -> 33 passed, 1 failed   (caught)
M2  $global:LASTEXITCODE=255 -> 34 passed, 0 failed  (no longer a false alarm)
M3  preset deleted         -> 33 passed, 1 failed   (still caught)
baseline                   -> 34 passed, 0 failed

The escaped \$ also resolves the portability half — grep -n 'if (\$sigDownloaded)' now returns line 329 under both /usr/bin/grep and the anchor-treating ugrep that made the old pattern match nothing. bash -n clean.

Anchoring the statement start-to-end is the right call over -F on the preset: it is the property that actually matters (the assignment is code, not prose), and it is what makes M1 and M2 come out opposite ways from the same edit.

One inherent consequence of the anchor, not worth another round: a trailing comment on the preset line ($global:LASTEXITCODE = 255 # no verdict yet) would now read as absent and turn case 19 red. That is the safe direction to fail, and loosening it is how the commented-out hole got in, so leaving it strict is the better trade.

The production one-liner in install.ps1 is unchanged from my first pass and still correct. The limitation the PR states up front stands and is worth its own ticket: this is a source assertion, and install.ps1 has no behavioural coverage — no pwsh, no Pester anywhere in CI — which is why a signature gate that did not gate reached a promotion PR in the first place.