fix(release): preserve signed Windows zip filename, match checksum format - #3556
Merged
Conversation
…rmat skip-decompress defaults to false, so the SignPath action was extracting the returned zip's contents as loose files instead of saving back the signed worktrunk-x86_64-pc-windows-msvc.zip — the checksum step would have silently hashed the still-unsigned zip. Also add sha256sum -b to match cargo-dist's own <hash> *<filename> checksum format.
worktrunk-bot
approved these changes
Jul 23, 2026
Merged
Merged
max-sixty
added a commit
that referenced
this pull request
Jul 25, 2026
Cuts v0.69.2, and fixes the Windows code-signing path it depends on. ## The signing fix v0.69.1 shipped an unsigned `wt.exe` under a green run and a **Completed** SignPath signing request. `archive: false` (#3566) had already made the GitHub artifact name `worktrunk-x86_64-pc-windows-msvc.zip`, and SignPath names its download after the artifact — so with `output-artifact-directory: target/distrib` the signed zip landed at `worktrunk-x86_64-pc-windows-msvc.zip.zip`, beside the untouched unsigned build. The checksum step and the release upload both kept reading the original. Confirmed by parsing the published asset's PE certificate table: `size=0`. The download now goes to a scratch directory and whatever single file lands there replaces the built zip, so SignPath's naming isn't load-bearing. ## Verification, because this failure is invisible Signing is `continue-on-error` by design (self-signed test certificate pending SignPath's OSS review), so nothing in the logs distinguishes "signed" from "silently unsigned" — which is how it slipped through twice, two different ways. `.github/verify-windows-signature.py` reads the zip's PE certificate tables directly, and runs at two points with distinct jobs: - **before the overwrite** — an unsigned release is tolerable while the certificate is a test one; a corrupt one never is, so the replacement has to verify before it can clobber a good build. - **after** — reports what the release actually ships, which is the question the logs never answered. ## Rehearsed before landing The signing path only runs on a tag, so each question about it used to cost a release. This chain was instead run on a Windows runner against the already-published v0.69.1 zip (identical bytes, no build): ``` saved to …\target\signpath\worktrunk-x86_64-pc-windows-msvc.zip.zip git-wt.exe: certificate table 8480 bytes wt.exe: certificate table 8472 bytes → mv → target/distrib/worktrunk-x86_64-pc-windows-msvc.zip target/distrib/worktrunk-x86_64-pc-windows-msvc.zip: all 2 executables signed worktrunk-x86_64-pc-windows-msvc.zip: OK (checksum matches) ``` That also settled the open question behind #3556: SignPath returns the signed zip itself, not a wrapper, so `skip-decompress: true` is correct — the extract mode does explode it into loose files. ## Release contents `wt remove`'s fsmonitor sweep (#3581), the troubleshooting doc trim, and this fix. The two refactors in range (#3582, #3584) are behavior-preserving and omitted per convention. Local gate green (4547 passed). Changelog entries verified against the diffs by subagent; two claims corrected (the doc entry's rationale, and an overclaim attributing v0.69.0's unsigned binary to this bug rather than the separate upload failure #3566 fixed). Data-loss surface reviewed across the cumulative diff. > _This was written by Claude Code on behalf of max_
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
skip-decompressdefaults tofalse, so it would have extracted the returned zip's contents as loose files intotarget/distrib/instead of saving back a signedworktrunk-x86_64-pc-windows-msvc.zip. The checksum step would have silently hashed the still-unsigned zip, and the release would have shipped unsigned Windows binaries with no CI failure to flag it.sha256sumwithout-bomits the*binary-mode marker; cargo-dist's own checksums use<hash> *<filename>(confirmed against a real release asset). Added-bto match.Confirmed via
gh run viewon #3553's own CI run thatbuild-local-artifactsis skipped on PRs in this repo, so this code path has never actually executed — this is the first real fix before it runs for real on a tagged release.Test plan
actionlint .github/workflows/release.yaml— no new warnings (same pre-existing shellcheck style notes as before)skip-decompressbehavior against the action's ownaction.ymlinput specv0.68.0)