Migrate Windows release signing to DigiCert STM keypair-alias#14729
Draft
cderv wants to merge 7 commits into
Draft
Migrate Windows release signing to DigiCert STM keypair-alias#14729cderv wants to merge 7 commits into
cderv wants to merge 7 commits into
Conversation
Collaborator
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Windows signing certificate expires 2026-08-19; security provisioned a new credential set (_2026-suffixed secrets, keypair-alias based). This is a spike to test whether smctl's own sign/verify subcommands work directly against the new credentials, without signtool.exe or smctl windows certsync, before deciding on a target architecture. Also adds an `os` workflow_dispatch input (all/linux/windows/macos, default all) so a single-platform signing test doesn't require running the full multi-platform release pipeline.
smctl sign --keypair-alias has no equivalent flag (per DigiCert's docs), and the new sign command never consumed this input, so the MSI description arg was being silently dropped. Remove the now-unused input and its caller rather than imply it's still honored.
smctl's --sigalg/--digalg default to "whatever the signing tool used supports" per DigiCert docs, unlike the old signtool.exe invocation which pinned /td SHA256 /fd SHA256 explicitly. Pin both rather than rely on an undocumented default. Also use --timestamp=true instead of the bare --timestamp flag, since DigiCert's docs only show the --timestamp=false boolean form.
The new os selector could skip Linux/macOS installer jobs while configure still bumped version.txt and pushed a tag (gated only on publish-release, not os). publish-release itself then auto-skips since its skipped needs aren't successes, but cleanup-when-failure only fires on failure()/cancelled(), not skipped -- leaving an orphaned version/tag commit with no corresponding release. Fail fast instead of publishing partial-platform releases.
llm-docs/code-signing-installers.md still described the old certsync/signtool.exe/CERT_FINGERPRINT flow, which would mislead anyone rotating DigiCert credentials or debugging signing into configuring the old secret set.
Reword the sign-step env comment now that this is the production path,
not a spike ("testing" was accurate pre-merge, misleading after).
Bump llm-docs frontmatter to the actual merge-base/date and drop an
unverified SM_HOST value claim traced to a second-hand doc handoff.
These are the two facts other maintainers will want next time this file needs touching: smctl's verify step turns out to shell out to signtool internally (confirmed from CI logs, not just docs), and the dropped MSI description flag was already invisible everywhere before removal, so its loss isn't a regression.
cderv
force-pushed
the
test/digicert-stm-2026-signing
branch
from
July 24, 2026 21:15
bc833e4 to
28b145a
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
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.
The DigiCert code-signing certificate used for Windows release signing expires 2026-08-19. IT/Security team provided a new credential set (
_2026-suffixed secrets) alongside the existing one, so the workflow can be migrated to the new certificate ahead of expiry while the old set stays available for rollback during the transition.Change
sign-files/action.ymlnow signs viasmctl sign --keypair-aliasdirectly against DigiCert, instead ofsmctl windows certsync+signtool.exe sign /sha1 <fingerprint>. Signature/timestamp are pinned explicitly (--digalg SHA256 --sigalg SHA256 --timestamp=true) rather than relying on tool defaults, and verification usessmctl sign verifyin place ofsigntool.exe verify /v /pa.create-release.yml'smake-installer-winjob now sourcesSM_HOST_2026/SM_API_KEY_2026/SM_CLIENT_CERT_FILE_B64_2026/SM_CLIENT_CERT_PASSWORD_2026/SM_KEYPAIR_ALIAS_2026, mapped to the unsuffixed env var names the tooling reads.The
signtools-extra-argsinput (used to pass/d "Quarto CLI"to the MSI signing step) is removed —smctl signhas no description/subject-name equivalent flag, so the input had no way to keep working. Manually checked the currently-released MSI's signature (Explorer > Digital Signatures > Details > Additional Information): the description text isn't visible there either, so this has no observable user-facing effect either way.Also added a
workflow_dispatchosinput (all/linux/windows/macos, defaultall) that gates the per-platform build/test jobs, so validating this signing change doesn't require running the full multi-platform release pipeline. A guard step fails fast ifpublish-releaseis requested together with a non-allos, since a partial-platform run can't produce a coherent release.Decisions
Stayed on the same job and runner (
windows-latest), rather than moving signing to a separate Linux job withosslsigncode+ a PKCS11 engine —smctl signtalks to DigiCert directly and doesn't need the Windows cert-store sync step, so no job split is needed.smctlstill delegates the actual Windows signing tosigntool.exeinternally, so the existing "add signtool to PATH" step stays in place.Considered adding
--tsa-urlto restore explicit timestamp-server pinning (dropped the previous/tr http://timestamp.digicert.com), but DigiCert's docs confirm the flag only records the URL in signature metadata — it doesn't select which TSA is actually used — so it was left out as a no-op.Test Plan
create-release.ymldoesn't run on pull request events, so the signing path needs a manualworkflow_dispatchrun before this is ready to merge:workflow_dispatchon this branch withpublish-release=false,os=windowssmctl signandsmctl sign verifysucceed in themake-installer-winjobquarto.exe/MSI withGet-AuthenticodeSignature:Status=Valid,HashAlgorithm=sha256, timestamp present from a DigiCert TSAOpened as draft until the above passes.