feat(ci): automate Windows MSI code signing via workflow_dispatch

[boscorat]

Summary

Automate Windows MSI code signing in CI using a workflow_dispatch trigger on a self-hosted runner with SimplySign Desktop. Evaluate both jsign and ssign as signing tools before committing to one.

Motivation

Currently, Windows MSI signing is a manual step: download the unsigned MSI from the draft release, sign locally with jsign + SimplySign Desktop, then re-upload. This works but requires the maintainer to be at their Linux machine with SimplySign Desktop connected.
Automating this via workflow_dispatch would allow signing from the GitHub Actions UI while keeping the same manual authentication flow (OTP from mobile app → SimplySign Desktop connected → signing runs).

Proposed approach

Phase 1: self-hosted runner with jsign (proven)

• Set up a self-hosted Linux runner with SimplySign Desktop + jsign pre-installed
• Create .github/workflows/sign-windows.yml triggered by workflow_dispatch
• Workflow: authenticate SimplySign (manual OTP) → download unsigned MSI → sign with jsign → upload signed MSI → verify with osslsigncode
• jsign is already proven to work with our PKCS#11 setup (tested locally)

Phase 2: evaluate ssign as alternative

• ssign is a newer Rust-based tool for Certum cloud signing
• Test ssign against the same SimplySign Desktop PKCS#11 setup
• Compare: reliability, ease of setup, CI integration, timestamp support
• Decision: adopt ssign if it matches or exceeds jsign, otherwise stay with jsign

Files to create/modify

• .github/workflows/sign-windows.yml — new workflow for workflow_dispatch signing
• RELEASE.md — update signing step to reference automated workflow
• docs/codesigning.md — document CI signing setup

Context

• Certum OV Open Source Code Signing certificate (CN=Open Source Developer Jason Telford Farrar)
• SimplySign Desktop installed at /opt/SimplySignDesktop/ on maintainer's Linux machine
• SunPKCS11 config at ~/provider_simplysign.cfg
• jsign 7.5 at ~/jsign/jsign.jar — proven working locally
• ssign v0.1.2 (current version but under active development)

Related

• Issue Certum Open Source Code Signing #75 (original Certum setup)
• docs/codesigning.md — current signing policy
• RELEASE.md — release workflow & promotion checklist

[Le-Syl21]

ssign author here — happy to see it on your list. Two corrections that change your Phase 1 quite a bit, so I'd rather flag them now than after you've built a runner.

It's Rust, not Python. Single static binary, no interpreter, no dependencies to install on the runner. There's a cargo install ssign, or prebuilt binaries for Linux/macOS/Windows (x86_64 and arm64) on the releases page.

It doesn't use SimplySign Desktop at all — that's the whole point of it, and it's why "test ssign against the same SimplySign Desktop PKCS#11 setup" won't quite work as written. ssign talks straight to Certum's cloud API over HTTPS: OAuth login with your e-mail plus a 6-digit code, fetch the card and certificate, send the SHA-256 digest, get the RSA signature back, and assemble the PKCS#7 itself. No desktop app, no p11-kit bridge, no virtual smart card.

The practical consequence for #119: you probably don't need a self-hosted runner. The reason you need one today is that SimplySign Desktop has to be running on a machine someone is sitting at. ssign has no such requirement — put the TOTP seed in CERTUM_OTP as a repository secret and it derives the 6-digit code itself at run time, so a stock ubuntu-latest runner can sign unattended. That's how ssign signs its own releases. If you'd rather keep a human in the loop, --token/CERTUM_TOKEN takes a code you read from your phone, which fits your workflow_dispatch flow directly.

Two caveats worth knowing before you commit:

• MSI is supported, but I have not tested it against a wide range of installers. ssign handles Authenticode for PE (exe/dll/sys) and MSI. If MSI is your only target, jsign is the more battle-tested choice today and I'd say so plainly.
• If you want to keep jsign, there's ssign-pkcs11 in the same repo — a PKCS#11 module that exposes the cloud key to jsign, osslsigncode or signtool. That's a drop-in replacement for the SimplySign Desktop half of your setup while you keep the signing tool you've already proven. It's distributed as a shared library in the release assets, not on crates.io.

One last thing: you reference v0.1.2 — v0.1.3 went out today, and it carries a real fix you'd want. When Certum returns several digests in one response, 0.1.2 took the first entry rather than the one matching the file being signed. Sign one file at a time and it never bites, but it's the kind of thing you don't want to discover in a release pipeline.

Timestamping is on by default (Certum's RFC3161 TSA), and the released binaries are themselves signed and timestamped if you want to check the output format before trusting the tool.

Happy to answer anything specific if you do try it — and equally happy to hear it if it doesn't fit; the MSI coverage gap is real and I'd rather you know it up front.

[Le-Syl21]

Forgot the most useful part of my last comment — there's a ready-made workflow for exactly your case in the README:

https://github.com/Le-Syl21/ssign#github-actions

It's workflow_dispatch-triggered on ubuntu-latest, which is the shape you described in Phase 1 minus the self-hosted runner:

on:
  workflow_dispatch:        # manual only — each run performs a real cloud signature

jobs:
  sign:
    runs-on: ubuntu-latest
    environment: signing    # protected environment
    steps:
      - uses: actions/checkout@v4
      - run: cargo install ssign
      - run: ssign dist/*.exe
        env:
          CERTUM_EMAIL: ${{ secrets.CERTUM_EMAIL }}
          CERTUM_OTP:   ${{ secrets.CERTUM_OTP }}

The section right below it ("Secure signing with owner approval") is worth reading even if you end up staying with jsign, because it addresses something your issue doesn't mention yet: with the seed sitting in CI, any workflow that can read that secret can spend your certificate. Putting it in a GitHub Environment with required reviewers means the secrets are unreadable until you approve the run from the Actions UI — so a pull request, including a malicious one, can't trigger a signature. That keeps the "manual authentication" property you wanted from the OTP-on-mobile flow, but the human step becomes "approve the run" instead of "be sat at the machine with SimplySign Desktop connected".

That pattern is the one ssign uses for its own releases, so it isn't theoretical.

[boscorat]

Apologies for the python / rust error! I know ssign is written in rust so not sure how I made that mistake - I've edited the description.

MSI is the only target at the moment, but it's possible this will change with user feedback. If the project gets much traction, we can always plan an alpha, beta or rc release for the v0.3.0 release using ssign for the msi binaries, and this might help with testing.

Thank you for all your input and guidance. The signing of windows binaries is a new area for me so it's proving to be something of a challenge!

[Le-Syl21]

No worries at all about the Rust/Python mix-up — easy to do when you're juggling half a dozen tools.

That plan makes a lot of sense: keep jsign for the MSIs you're shipping now, and if you do a v0.3.0 pre-release, that's a low-stakes place to try ssign in parallel. If you go that route I'd genuinely like to hear how it does — MSI is the one corner of Authenticode I've had the least real-world coverage on, so a couple of your installers going through it would tell me more than my own test files can. And if something misbehaves, send me the installer (or just the --verbose output) and I'll dig in.

Windows signing is genuinely fiddly the first time — the cloud-HSM + timestamp + PKCS#7 dance has a lot of moving parts. Shout if you hit anything, whichever tool you land on.