#36673 [DRAFT] ci: Monitor Windows signing certificate expiry

ReviewabilityReviewsAgreementSize
#36673 willcl-ark [DRAFT] ci: Monitor Windows signing certificate expiryReady0Strong76
  • Alert maintainers when the Windows code signing certificate is expiring or expired
  • Prevents expedited or point releases from being delayed by an unexpected expired certificate
  • Ready for review
  • No review verdicts recorded
  • Strong support for automated monitoring over manual release checks (fanquake)
  • Emphasizes certificates must always work for expedited and point releases (fanquake)
  • Open suggestion to make the check script standalone so it can run locally (maflcko)
  • 76 lines added or modified outside tests
  • 0 lines added or modified in tests
  • 0 lines removed in total
  • 1 files, 1 commits
Build and CI#27 of 56
P3 · new feature
  • P3 because it automates certificate monitoring to avoid surprise release blockers
  • Replaces manual tracking with weekly alerts so keys are always ready for urgent releases
  • Provides clear operational value for maintainers while remaining reasonably deferrable
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Adds a scheduled GitHub Actions workflow that runs weekly to verify the validity and expiration date of the Windows code signing certificate. If the certificate is within 90 days of expiry or has already expired, the job opens an issue in the repository with certificate details and the checked commit. Duplicate issues are prevented by searching for existing open or closed issues matching the expiry title.

Problem: There is no automated monitoring for code signing certificate expiration, forcing maintainers to rely on release candidate cycles to discover expired certificates. If a minor or bugfix release must be published on short notice, discovering an expired certificate at that moment can delay the release.

Evidence of importance:

  • PR description: 'Currently we have no automation in place to check that our code signing certificates are not expired or close to expiry. We have previously "relied on Release Candidates" as a dry-run for codesigners to realise that a certificate has expired and have time to fix it.'

Risk of a mistake: low (tooling). A bug in the workflow could fail to alert developers to certificate expiration or create duplicate GitHub issues.

Changed since the previous assessment: The core approach remains unchanged from the previous version.

Reviewability

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

  • author: response to maflcko's suggestion to make the script stand-alone 2026-10-30
  • reviewer: fanquake to clarify availability of macOS cert in response to author's question 2026-10-30

Agreement

Strong

substantive support, no open objection (fanquake, fanquake)

Thread notes: Added fanquake's suggestion regarding macOS code-signing checks (answered by author) along with his supportive rationale, and recorded maflcko's suggestion to make the verification script standalone.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
hebasto (member)question, approachWhat is the rationale for the length period?answered · author explained it was a placeholder dependent on renewal lead time; achow101 provided renewal lead time dataansweredyes2026-10-27: 'What's the rationale for this length period?'
Status from: 2026-10-27: willcl-ark: 'There is no current rationale for this, it's a placeholder for now.'
hebasto (member)suggestion, approachAmend the release process to track cert expiry instead of adding CI automationanswered · author is open to either approach; fanquake argued automated CI is required for expedited and point releasesansweredyes2026-10-29: 'Alternatively, we could amend the release process as suggested in https://github.com/bitcoin/bitcoin/issues/36695#issuecomment-6505826743.'
Status from: 2026-10-29: willcl-ark: 'Yep! No skin off my back either way; happy with either approach.'
hebasto (member)question, correctnessIs anything enforcing the order of the certificates?answered · fix pushed · author confirmed nothing enforced it and pushed an amendmentansweredyes2026-10-29: 'Is anything enforcing that order?'
Status from: 2026-10-29: willcl-ark: 'There is not (nice question).'
fanquake (member)suggestion, scopeAdd a similar check for macOS code-signinganswered · author noted the macOS cert is not in the repo but offered to add the check if availableansweredyes2026-10-30: 'I think we should also add a similar check for macOS code-signing'
Status from: 2026-10-30: willcl-ark: 'To my knowledge the cert is not checked into this repo? but otherwise can trivially add the second check.'
maflcko (member)suggestion, approachMake the script stand-alone so that it can be run locallyopenansweredno2026-10-30: 'the script should probably be stand-alone, so that it can be run locally?'

Support:

  • fanquake (member) (2026-10-29): The certs are constantly used to produce (point) releases, not just major releases, so *always* need to work (particularly in the case of expedited releases, like this week).
  • fanquake (member) (2026-10-30): Automating the check moves away from manual tasks that someone might forget, providing automated assurance that certificates are not expired or arbitrarily revoked.

Participants:

  • achow101 (member, neutral, 1 statements 2026-10-27 to 2026-10-27): provided information on certificate renewal lead times
  • hebasto (member, question, 3 statements 2026-10-27 to 2026-10-29): asked about cert order enforcement and suggested amending the release process instead
  • fanquake (member, support, 2 statements 2026-10-29 to 2026-10-30): supports automated monitoring over manual release process checks and suggested adding macOS cert monitoring
  • maflcko (member, neutral, 2 statements 2026-10-29 to 2026-10-30): questioned CI reliability and suggested making the monitoring script stand-alone

Files

0 lines under test/bench/ci.

  • .github/workflows/code-signing-certificate.yml +76/-0

Card

The short text the ranking pass compares across PRs.

Adds a weekly GitHub Actions workflow to check the Windows code signing certificate and open an issue if it expires within 90 days. Bitcoin Core currently has no automated monitoring for certificate expiration, relying on release candidate cycles for codesigners to discover expired certificates. The author notes that relying on regular release cycles is prone to delaying urgent, short-notice bugfix releases. Duplicate issues are suppressed by checking for existing open or closed expiry reports.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-31T01:18, confidence high, input hash fecefe81a6f0cfe9
thread read through 2026-10-30 (15 statements), head b7e371b634
labels: Windows · draft

Categories

Build and CI

P3 · new feature

Automates checking for certificate expiration so expedited and minor releases are not unexpectedly blocked by an expired signing key. As fanquake noted, automated checks replace manual tracking for certificates that 'always need to work (particularly in the case of expedited releases)', providing clear operational value while remaining reasonably deferrable.

Membership: Adds a new GitHub Actions workflow file under .github/workflows/ to automate Windows code signing certificate checks.

Factors: security/stability 1, bug 0, performance 0, user value 0, leverage 1