Uh oh!
There was an error while loading. Please reload this page.
ci(windows): delete the dead Authenticode signing step - #51
Conversation
windows.yml carried a `sign exe` step gated on secrets.WINDOWS_CERT_PFX_BASE64, a secret that has never been set. The step had therefore never run, every Windows release we have shipped is unsigned, and the workflow read as though the opposite were true. That was not cosmetic. A security review of this repo produced a wrong, unshippable recommendation off the back of it — "verify the extracted exe's Authenticode signature before ApplyUpdate" — which would have rejected every genuine update, because there is no signature on any of them. Config that looks load-bearing and isn't generates bad downstream decisions, so per the decision on #9 it goes rather than staying as a placeholder. Removed: the `sign exe` step, the now-unused `signed` output from `determine build mode` (and with it the only reference to the cert secrets), and the signing language in the header. The header now states plainly that builds are unsigned and SmartScreen will warn, records why the step was deleted so nobody "restores" it as an oversight, and says what to do to add real signing — provision the secrets in the same change, and scope them to an Environment (#20) rather than the repo. Also corrects the publish step's comment, which cited signing as a defence against a leaked contents:write token. On Windows that defence is the build provenance attestation (#24) and nothing else. No functional change to what ships: the step never executed, so the artifacts are byte-for-byte what they were. Closes#9
Uh oh!
There was an error while loading. Please reload this page.
z33b0t
commented
Jul 29, 2026
@z33b0t ready to merge. All 7 checks green, including I also verified the artifact, using the same method the issue used to establish the problem. Downloaded the zip this PR's run produced and parsed the PE optional header: Identical to what #9 measured against the published v0.2 asset. That is the point: nothing about the shipped binary changes, because the deleted step never executed. The build still produces a valid 72 MB single-file PE32+ exe. Confirms the workflow and reality now agree, rather than the file describing a signing path that never ran. You'll need to merge this one — it touches |
Takes option 2 from #9. The
sign exestep was gated onsecrets.WINDOWS_CERT_PFX_BASE64, which has never been set — so it had never run, every Windows release we've shipped is unsigned, and the workflow read as though the opposite were true.That's the part worth restating: it wasn't cosmetic. A security review of this repo produced a wrong, unshippable recommendation off the back of it — "verify the extracted exe's Authenticode signature before
ApplyUpdate" — which would have rejected every genuine update. Config that looks load-bearing and isn't generates bad downstream decisions.Removed
sign exestepsignedoutput fromdetermine build mode— which was the only remaining reference to the cert secretsTwo things I did beyond deleting
mainorv*tag, so write access is enough to have CI sign a payload.contents:writetoken is defended against by "signing … and build provenance". On Windows that's now provenance (Release artifacts carry no build provenance attestation #24) and nothing else. That sentence was part of the same misleading picture.Verification
steps.*.outputs.*reference still resolves (cfg.release,ver.version,artifact.zip,artifact.name) — the deletedsignedoutput has no remaining consumersThe README was already corrected in #39 to stop claiming signed builds, so docs and workflow now agree.
Note: this touches
.github/workflows/, so I can't merge it — sameworkflowscope block as #40.Closes#9