>26.0.1 gets stuck on Windows signing the squirrel exe

[t3chguy]

Before update (26.0.1) https://github.com/element-hq/element-desktop/actions/runs/13175306673/job/36773250686
After update to 26.0.6 https://github.com/element-hq/element-desktop/actions/runs/13196581336/job/36839196683 it errors when calling upon a vendored signtool.exe from electron-winstaller/electron-windows-sign - the signing we use via eSignerCKA requires a rather modern signtool so we prefer the system one by use of the SIGNTOOL_PATH envvar which electron-builder respects.

electron-win-sign however does not respect it, it instead reads WINDOWS_SIGNTOOL_PATH upon changing to which signing just seems to hang. https://github.com/element-hq/element-desktop/actions/runs/13197854827/job/36843095558

I'm surprised to see D:\a\element-desktop\element-desktop\node_modules\electron-winstaller\vendor\signtool.exe being called given e-b is passing a signing hookFunction so should be using its own signtool handling -

electron-builder/packages/electron-builder-squirrel-windows/src/SquirrelWindowsTarget.ts

Lines 144 to 150 in f4fc04a

	if (await (await packager.signingManager.value).cscInfo.value) {
	options.windowsSign = {
	hookFunction: async (file: string) => {
	await packager.sign(file)
	},
	}
	}

Maybe that if-statement isn't being entered due to the condition not doing the same thing as the old signing code - looks like other areas in the code just look at options.sign potentially https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/platformPackager.ts#L370

[t3chguy]

On a retry with debug logging enabled it seems to hang directly after signing the MSI https://github.com/element-hq/element-desktop/actions/runs/13200748516/job/36851975119

[t3chguy]

electron-builder run with debugging and crash from electron-windows-sign due to it not using e-b's packager.sign: https://github.com/element-hq/element-desktop/actions/runs/13204321507/job/36863804553

the reason I believe WINDOWS_SIGNTOOL_PATH to not work is because the other parameters (subject name & certificate sha) are not being passed by e-b as its relying on handling signing itself but fails to do so.

[t3chguy]

I've had to roll back to get code signing working again which is a shame as it means I lost ARM64 support. I will set up a better environment to test including code signing before the next e-b upgrade -= element-hq/element-desktop#2131 should be that

[beyondkmp]

@t3chguy Do you use a custom sign function?

[beyondkmp]

if CSC_LINK is used, electron-builder does have unit tests (UT) to ensure that signing can pass.

test.ifAll.ifNotCiMac(
  "Squirrel.Windows",
  app(
    {
      targets: Platform.WINDOWS.createTarget(["squirrel"]),
      config: {
        win: {
          compression: "normal",
        },
        executableName: " test with spaces",
        electronFuses: {
          runAsNode: true,
          enableCookieEncryption: true,
          enableNodeOptionsEnvironmentVariable: true,
          enableNodeCliInspectArguments: true,
          enableEmbeddedAsarIntegrityValidation: true,
          onlyLoadAppFromAsar: true,
          loadBrowserProcessSpecificV8Snapshot: true,
          grantFileProtocolExtraPrivileges: undefined, // unsupported on current electron version in our tests
        },
      },
    },
    { signedWin: true }
  )
)

[t3chguy]

@t3chguy Do you use a custom sign function?

No, we pass signtool options of subject Name and sha1. We also specify the signtool executable via environment as we need a modern one which is compatible with the eSignerCKA

[beyondkmp]

This issue can be reproduced in the GitHub Action. However, signing works fine locally on Windows 11, and the problem cannot be reproduced there. The machines in GitHub Actions run on Windows Server 2022. It's still unclear why it fails in GitHub Actions, and it will take some time to investigate the cause.

[t3chguy]

The fact that the vendored signtool is being executed rather than the one specified in SIGNTOOL_PATH is issue enough. Based on the debug logs looks like the sign hook isn't being passed due to the if-statement not triggering.

[beyondkmp]

However, when I tested it locally, I was able to use the electron-builder sign function without any issues. From the error logs, it seems that the process did enter the electron-builder sign function, but the failure was caused by an issue with the win option parameter at the end.

[t3chguy]

@beyondkmp if you look at https://github.com/element-hq/element-desktop/actions/runs/13204321507/job/36863804553#step:17:599

...
• signing with signtool.exe  path=dist\Element Nightly 0.0.1-nightly.2025020701.msi
  • signing         file=dist\Element Nightly 0.0.1-nightly.2025020701.msi subject=OID.1.3.6.1.4.1.311.60.2.1.3=GB, OID.2.5.4.15=Private Organization, CN=NEW VECTOR LTD, SERIALNUMBER=10873661, O=NEW VECTOR LTD, L=London, C=GB thumbprint=ED8CD4DF9BD2ED1B68CD98F28333B33E755BB911 store=My user=current user
  • executing       file=C:/Program Files (x86)/Windows Kits/10/bin/10.0.22000.0/x86/signtool.exe args=sign /tr http://timestamp.digicert.com/ /sha1 ED8CD4DF9BD2ED1B68CD98F28333B33E755BB911 /s My /fd sha256 /td sha256 /d Element Nightly /du https://element.io/ /debug D:\a\element-desktop\element-desktop\dist\Element Nightly 0.0.1-nightly.2025020701.msi env={}
  • executed        file=C:/Program Files (x86)/Windows Kits/10/bin/10.0.22000.0/x86/signtool.exe stdout=
The following certificates were considered:
    Issued to: NEW VECTOR LTD

    Issued by: SSL.com EV Code Signing Intermediate CA RSA R3

    Expires:   Mon Mar 16 15:47:01 2026

    SHA1 hash: ED8CD4DF9BD2ED1B68CD98F28333B33E755BB911

                      After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Hash filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
    Issued to: NEW VECTOR LTD

    Issued by: SSL.com EV Code Signing Intermediate CA RSA R3

    Expires:   Mon Mar 16 15:47:01 2026

    SHA1 hash: ED8CD4DF9BD2ED1B68CD98F28333B33E755BB911

                      Done Adding Additional Store
Successfully signed: D:\a\element-desktop\element-desktop\dist\Element Nightly 0.0.1-nightly.2025020701.msi

                      Number of files successfully Signed: 1

Number of warnings: 0

Number of errors: 0


  ⨯ Failed with exit code: 4294967295
Output:
System.AggregateException: One or more errors occurred. ---> System.Exception: Failed to sign, command invoked was: 'D:\a\element-desktop\element-desktop\node_modules\electron-winstaller\vendor\signtool.exe sign windows-sign C:\Users\runneradmin\AppData\Local\SquirrelTemp\tempa\lib\net45\Element Nightly_ExecutionStub.exe'
   at Squirrel.Update.Program.<signPEFile>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
...

You can see a successful electron-builder sign using C:/Program Files (x86)/Windows Kits/10/bin/10.0.22000.0/x86/signtool.exe on dist\Element Nightly 0.0.1-nightly.2025020701.msi
Followed by a failure using D:\a\element-desktop\element-desktop\node_modules\electron-winstaller\vendor\signtool.exe on C:\Users\runneradmin\AppData\Local\SquirrelTemp\tempa\lib\net45\Element Nightly_ExecutionStub.exe

From the error logs, it seems that the process did enter the electron-builder sign function

It looks like for squirrel signing this function is not entered as there's no signing log block for it.

[beyondkmp]

https://github.com/electron/windows-installer/blob/e722a519f8625c939087de2602b2b5b594886bc4/src/sign.ts#L13

Based on the source code of the Windows installer, if the windowsSign parameter is set, it will replace the signtool.exe in the vendor directory with a fake sign tool to support this parameter. Currently, it seems that the replacement did not succeed on GitHub Actions, and the real signtool.exe is still being used, which does not support the windowsSign parameter, leading to the signing failure.

In my local tests, it succeeded because everything was on the same C drive. However, I noticed that on GitHub Actions, the data and node_modules are on different drives — one on the C drive and the other on the D drive. This difference might be the cause of the issue.