Windows Authenticode code-signing for release binaries (funding-gated)

[githubrobbi]

Context

Phase 0 trust-stack audit found this is the one trust item not yet in place. Releases already ship SLSA build-provenance attestations, per-crate CycloneDX SBOMs, and CHECKSUMS.txt — strong supply-chain signals — but the Windows binaries are not Authenticode-signed, so users still hit a SmartScreen/"unknown publisher" prompt on first run.

Why it's gated

An Authenticode (ideally EV/OV) code-signing certificate is a recurring annual cost. This is explicitly one of the things sponsorship is meant to fund — see the README "Sponsorship" section and donation_readiness_playbook.md. It's a chicken-and-egg item: signing improves install conversion, but the cert is funded by sponsors. Tracking it rather than blocking the rollout on it.

Done =

• Acquire an OV/EV code-signing certificate (or a cloud signing service, e.g. Azure Trusted Signing).
• Wire signing into the release pipeline after artifact build, before checksums/attestation, so CHECKSUMS.txt covers the signed binaries.
• Sign uffs, uffsd, uffsmcp (+ TUI) Windows .exes.
• Document verification (signtool verify /pa) alongside the existing gh attestation verify step in the README.
• Confirm a fresh Windows 10/11 install no longer shows the "unknown publisher" SmartScreen warning.

Notes

• Cloud options (Azure Trusted Signing, SignPath OSS program) may avoid an upfront EV cert purchase and integrate with GitHub Actions — worth evaluating first.
• Keep the secret/cert handling out of the repo; use Actions secrets / OIDC.