fix(installer): bootstrap the amd64 cosign on Windows-on-ARM — the arm64 asset does not exist (client#734)

[LukasWodka]

Closes#734. Unblocks the cli port in tracebloc/backend#2078.

The bug

Resolve-Cosign built cosign-windows-$arch.exe. On Windows-on-ARM that asks for cosign-windows-arm64.exe — an asset sigstore has never published:

v2.4.1 (pinned) → cosign-windows-amd64.exe (only Windows asset)
v3.1.3 (latest) → cosign-windows-amd64.exe (only Windows asset)

404 → Resolve-Cosign returns $null → fail closed. The direction is right; the reason is accidental. The user sees a cosign download failure that reads as a transient network problem, and no amount of retrying can conjure the asset.

Why now

backend#2078 proposes porting this exact function into cli/scripts/install.ps1, which today skips signature verification altogether. Copying it as-is would carry the broken arch map into a second installer — and the CLI is the more exposed one, because its release matrix really does build windows/arm64. So ARM users get a native binary and nothing able to verify it. Fixing it here means that port is a copy of one correct function.

Why amd64-under-emulation is the right answer, not a compromise

cosign verifies a signature over bytes. The instruction set it was compiled for cannot change the verdict, and the artifact handed to it is still the native arm64 binary. The bootstrapped cosign is checksum-verified against sigstore's own published list before use, exactly as on amd64 — the trust chain is byte-for-byte identical.

The alternative — fail closed with a winget install sigstore.cosign hint — routes the user to do the same thing by hand, because winget's cosign is also amd64-only. Same end state, more friction, and one more opportunity to reach for TRACEBLOC_ALLOW_UNVERIFIED=1, which is the outcome we least want.

Second half: a verifier that won't start is not a bad signature

Invoke-CosignVerifyBlob already fails closed on a binary that cannot execute — but reported it identically to a signature that did not verify. On an older Windows 10 on ARM without x64 emulation, that tells a user their download may be tampered with when the truth is "the verifier won't start on this machine."

Those warrant opposite reactions, and only one of them is a security event. A cosign version probe after resolution separates them:

• still fails closed
• says plainly that this is not a failed verification
• names x64 emulation as the likely cause and gives a remedy that works
• honours TRACEBLOC_ALLOW_UNVERIFIED loudly, like the sibling path

Test plan

make check green · Pester 680 passed, 0 failed across the suite.

Both halves mutation-real:

--- restore $asset = "cosign-windows-$arch.exe" ---
[-] requests the amd64 cosign asset unconditionally — never a per-arch name
--- drop the Test-CosignRuns probe ---
[-] fails closed, and says the download is NOT implicated
[-] names the real cause and a remedy that works on Windows-on-ARM
[-] never reaches the verify when cosign can't run
[-] honours TRACEBLOC_ALLOW_UNVERIFIED, loudly, like the other unverified path

Also pinned: the unknown-architecture refusal still stands, and the bootstrapped cosign is still checksum-verified — so the fix cannot be mistaken for loosening the trust chain.

Reviewer note

CI cannot exercise the ARM path — GitHub's Windows runners are x64, so no test here will ever run on the hardware this fixes. The arch-map coverage is deliberately source-level for that reason, and the comment inside Resolve-Cosign is load-bearing: it is the only thing that will stop someone "correcting" amd64 back to $arch.

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches the installer’s cosign bootstrap and manifest signature gate (supply-chain trust root); behavior is more permissive on ARM when amd64 cosign runs under emulation, but trust chain and fail-closed defaults remain.

Overview
Fixes Windows-on-ARM installs that failed because Resolve-Cosign requested cosign-windows-arm64.exe, which Sigstore never ships—only cosign-windows-amd64.exe exists. Both AMD64 and ARM64 now bootstrap that amd64 asset; checksum verification of the bootstrapped binary is unchanged.

Adds Test-CosignRuns (cosign version with the same LASTEXITCODE sentinel as verify) and runs it in Confirm-ManifestSignature before any verify-blob. If cosign cannot execute (AV quarantine, or ARM without x64 emulation), the installer still fails closed but explains this is not a failed signature and does not suggest winget install sigstore.cosign (same amd64 build). TRACEBLOC_ALLOW_UNVERIFIED still allows checksum-only proceed with warnings.

Pester coverage locks the amd64 asset name, executability probe, error wording, and no-verify path when cosign won’t run.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 099ec15. Configure here.}

[saadqbal]

Clean, careful PR. cosign-windows-amd64.exe is the right (and only) Windows asset; the switch still guards unknown arches, the checksum step is untouched, and install.sh/Linux-arm64 aren't in scope. Nice touch adding Test-CosignRuns so a non-executable cosign (Win10-on-ARM, no x64 emulation) fails closed with the true reason instead of masquerading as a bad signature. Tests are non-vacuous and green (40/40 on Pester 5.7.1). 👍

[LukasWodka]

/fr-pass

Best-effort functional review passed (triage: merged clean, non-interactive; behavioral evidence limited while e2e journey is red — backend#2206). Advancing to Ready for prod.