Update expired Windows certificate and release workflow

[nop33]

Microsoft changed the way they provide code-signing certificates. They want the signing to be FIPS-140 compliant. That's a very restrictive security standard. Our current release workflow that uses electron-builder needs to be updated.

Related issues:

• June 2023 Code Signing with HSM APIs electron-userland/electron-builder#7605
• Signing a windows application in Mac Os using a private key located in Yubikey (Fips 140) electron-userland/electron-builder#7895

[nop33]

This might be helpful: electron-userland/electron-builder#6158 (comment)
Also related, electron-builder windows config: https://www.electron.build/configuration/win
Especially this: How do delegate code signing? https://www.electron.build/configuration/win#how-do-delegate-code-signing
And this tutorial: https://www.electron.build/tutorials/code-signing-windows-apps-on-unix#integrate-signing-with-electron-builder

[nop33]

Ledger is utilizing the sign hook of electron-builder with their own script.

[nop33]

Summary of current status

Our app's executables are being built using electron-builder as a step in our release-desktop.yml GitHub workflow (through the nop33/action-electron-builder GitHub action). That's how the following release files get generated:

• .exe: executable binary
• .exe.blockmap: stores delta between version updates
• .exe.checksum: well, checksum, dah
• latest.yml: used by the updater to refer to the latest version, .exe, and hash of .exe

@killerwhile has implemented the signing of the above .exe as an additional step of our release-desktop.yml GitHub workflow using the GitHub action sslcom/esigner-codesign.

Problem

The .exe.blockmap, .exe.checksum and latest.yml are created BEFORE the signed Windows .exe file is created: #272. This breaks the checksum check and the auto-update system.

Possible solution 1

Thankfully, electron-builder exposes the sign hook in their config. This allows us to create a signWindows.js file that will be used to sign the .exe BEFORE creating all release-additional files:

// package.json

"build:{
  "win": {
    "sign": "signWindows.js",
  },
},

So, the idea is:

💡 Don't use the sslcom/esigner-codesign GitHub action as a step of our GitHub workflow and create a JS file to do the signing.

This is what this person has done.

I started working on this idea by creating a .signWindows.js file and hooking it up to the electron-builder config (see this WIP PR: #276)

I am stuck at this problem: How do I make the CodeSignTool-v1.3.0-windows executable available to the script? It's 333Mb big and I don't think we should commit that to our repo... Wouldn't it make sense that the JS script downloads and unpacks the CodeSignTool and somehow caches it instead of downloading it on every CI run?

The source code of the GitHub action the @killerwhile used, suggests that this is what they do.

Possible solution 2

Another person managed to solve this using the codesign support in electron-builder along with SSL.com's Cloud Key Adapter.

Related sources

• electron-builder Windows config: https://www.electron.build/configuration/win
  • especially How do delegate code signing?: https://www.electron.build/configuration/win#how-do-delegate-code-signing
• how to do Code Signing via esigner from ssl.com without USB Token? electron-userland/electron-builder#6158 (comment)

[killerwhile]

The second option is also downloading the eSigner tool, but a version which is only 15MB (https://github.com/element-hq/element-desktop/blob/develop/.github/workflows/build_windows.yaml#L117C1-L117C153).
A more official version seems to be here: https://github.com/SSLcom/eSignerCKA/releases