w64devkit locks its releases so even the maintainer cannot edit them
Serguey Asael Shinder3 min readChris Wellons has written up a year of changes to w64devkit, the portable C and C++ development kit for Windows, at https://nullprogram.com/blog/2026/09/20/. Most of it is supply-chain work, and it is a useful model for any small project that ships binaries.
Everything is signed. All EXEs and DLLs in a release are code-signed. The signing key earned reputation with security software the hard way — roughly 300 binaries per release across about 100,000 hosts produced thousands of unique signatures — and the tool used to do it, aas-sign, has since been adopted by MSYS2 and ships inside w64devkit.
Builds are triggered by a tag push, and only the maintainer can push one. GitHub Actions does the signing and creates the release, with every step derived from source in the repository rather than from anything local.
Releases are immutable. Once published, artefacts are locked: nobody — including the maintainer — can modify them, and a release attestation appears at the end of the artefact listing. The stated purpose is blunt: nobody involved in the project later can go rogue and quietly alter an old release.
On the toolchain itself, the x64 release is now multilib — it can also build 32-bit Windows binaries, so the separate x86 release exists only for old hardware and old Windows, targeting Windows XP and requiring SSE2. Use -m32, or better the i686-w64-mingw32 prefixed tools, which pick the right switches for you. GCC no longer needs bin/ on PATH to find its own tools, thanks to a small patch, so it can be invoked by absolute path from scripts.
And a detail that will save somebody a day: the COFF object format allows 65,535 sections, which modern C++ debug builds full of lambdas exceed. Binutils had been patched to emit bigobj always, which broke consumers that cannot read it — the Go toolchain's linker among them — and offered no way back. It now upgrades to bigobj only when needed, so large programs work and naive linkers and format-detection scripts still see standard COFF.
What it means
Immutability is the cheapest supply-chain control nobody enables. Signing proves who built an artefact; immutability proves the artefact has not been swapped since. The second is the one that defends against the compromise of the person doing the signing, which is the scenario every recent registry incident actually involved — and it costs one setting.
"Only a tag push from me triggers a build" removes the local machine from the chain. Any release built on a laptop has that laptop in its trust boundary. Moving the build to a runner that starts from the repository and nothing else is what lets the phrase "reproducible from source" mean something to a stranger.
And the bigobj fix is a small lesson about defaults. Always-on was correct for the failure it addressed and wrong for everyone downstream who could not consume the output. A default that adapts to the input — standard COFF until the section count demands more — serves both populations, and it took someone noticing that the Go linker was collateral damage.