ci: Sign Windows release builds with Azure Artifact Signing - #714
Merged
Merged
Conversation
CoffeeFlux
force-pushed
the
ci/windows-signing
branch
2 times, most recently
from
October 4, 2026 19:41
97af6db to
74601eb
Compare
CoffeeFlux
force-pushed
the
ci/windows-signing
branch
2 times, most recently
from
October 4, 2026 20:37
aeecfd6 to
4ef9236
Compare
Windows builds of v* tags are signed using Azure Artifact Signing, with an identity that only the release environment can use (through GitHub OIDC, so there are no stored secrets). The build never has access to that identity. Instead, release builds hand their output to new jobs, which sign the executable, rebuild the installer and portable zip around the signed copy, and then sign the installer. Signing happens in a small reusable workflow, sign-windows.yml, which doesn't check out or run any repository code and checks the resulting signature and publisher. Repackaging reuses win-installer-setup.ps1 (with a new -NoBuild switch, as there is no Meson build tree) and a new script that swaps the signed executable into the portable zip. Builds that aren't signed are unchanged, apart from the workflow's token now being read-only. The ci/windows-signing branch is also allowed to sign so that the setup can be tested with workflow_dispatch before a release.
CoffeeFlux
force-pushed
the
ci/windows-signing
branch
from
October 4, 2026 21:29
4ef9236 to
f194f1f
Compare
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
1 participant
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.
Signs the Windows release artifacts using Azure Artifact Signing.
How it works. Windows builds of
v*tags hand their output to three jobs instead of uploading it directly:windows-sign-executablesignsaegisub.exe.windows-packagerebuilds the installer around the signed executable and swaps it into the portable zip. This reusestools/win-installer-setup.ps1with a new-NoBuildswitch (there's no Meson build tree in that job; the build hands over the compiled translations,git_version.h, andinstaller-deps), plus a smallreplace-executable.ps1for the zip.windows-sign-installersigns the installer.Both signing jobs call the new reusable workflow
.github/workflows/sign-windows.yml. The final artifacts keep their existing names (Windows MSVC Release - installer/- portable); intermediate ones are prefixed withWindows signing -.Trust boundary. Only
sign-windows.ymlruns in thereleaseenvironment and getsid-token: write. It doesn't check out or run any repository code: it downloads one artifact, checks it's a single.exe, signs it, verifies the signature, timestamp, and publisher, and uploads it. Its actions are pinned to commits, and the signing action's dependency cache is disabled. The build (including subprojects and tests) and packaging never have access to the signing identity.Authentication. GitHub OIDC with a federated credential for
repo:TypesettingTools/Aegisub:environment:release, so there are no stored secrets. The Azure identity only holds the signer role on the certificate profile. The environment only admitsv*tags andci/windows-signing(for testing). Its settings live in environment variables (AZURE_CLIENT_ID,AZURE_TENANT_ID,ARTIFACT_SIGNING_ENDPOINT,ARTIFACT_SIGNING_ACCOUNT,ARTIFACT_SIGNING_PROFILE,ARTIFACT_SIGNING_PUBLISHER).Behavior changes. Non-release builds are unchanged, except that the workflow's
GITHUB_TOKENis now read-only, which nothing in it needed beyond. For release builds, the signed Windows artifacts are only produced if the whole build matrix succeeds.Not covered: the Inno Setup uninstaller is still unsigned, and VSFilter is shipped as-is. Once merged,
ci/windows-signingshould be removed from the environment's allowed branches.