mirror of
https://github.com/oven-sh/bun
synced 2026-02-28 20:40:59 +01:00
5b8b72522c
## What does this PR do?
Moves Windows code signing from an inline CMake `POST_BUILD` step to a
dedicated Buildkite step (`windows-sign`) that runs on an x64 agent
after all Windows builds complete.
### Why
DigiCert `smctl` is x64-only and silently fails under ARM64 emulation.
With the old inline approach, ARM64 builds were never signed (`ci.mjs`
skipped it with `target.arch !== "aarch64"`). Now that we're shipping
Windows ARM64, we need all Windows binaries signed.
### How it works
```
windows-x64-build-bun ─┐
windows-x64-baseline-build-bun ├─→ windows-sign (x64 agent) ─→ release
windows-aarch64-build-bun ─┘
```
The `windows-sign` step:
1. Downloads all 6 Windows zips (x64, x64-baseline, aarch64 × {release,
profile})
2. Extracts each, signs the exe with smctl, re-packs
3. Re-uploads with the **same filenames**
4. `upload-release.sh` pins Windows artifact downloads to `--step
windows-sign` to guarantee signed zips are released
### When signing runs
- On `main` with non-canary builds (normal release path)
- When `[sign windows]` is in the commit message (for testing on a
branch — **this PR uses it**)
Canary builds are never signed (DigiCert charges per signature).
### Cleanup
- Removed `ENABLE_WINDOWS_CODESIGNING` CMake option
- Removed inline `POST_BUILD` signing from `BuildBun.cmake`
- Removed SM_* secret fetching from `scripts/build.mjs`
- Replaced `sign-windows.ps1` (2-exe signer) with
`sign-windows-artifacts.ps1` (batch zip signer)
### Testing
The commit message contains `[sign windows]` so this PR's CI should run
the sign step. Will verify:
- All 6 zips are downloaded, signed, re-uploaded
- `Get-AuthenticodeSignature` verification passes for each exe
- smctl healthcheck works on the x64 test agent
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>