feat: update signtool.exe to10.0.22621.2428

[dopry]

this version supports the /dlib and /dxml arguments required for azure signing.

I appreciate the integration of windows-sign, but it's failing when called via makerSquirrel and I'm not really getting useful errors out of it. here is an updated signtool that might make it possible for me to sign without subbing out vie the substituted sea signtool.exe from windows-sign...

[MarshallOfSound]

Unfortunately we can't accept exe modifications from non-maintainers as we have no way to truly verify origin or authenticity.

@electron/wg-ecosystem can someone look into updating these?

@dopry Can you outline / raise an issue with exactly why you can't use the @electron/windows-sign options to solve this on your side of the build pipeline?

[dopry]

They're all signed binaries from MS you can check the signatures and checksums.

As I said in the op, the new sign library simply fails when passing the arguments required for azure trusted signing and doesn't yield a meaningful error. I can't get details now, getting my kids ready for school .. but are you sure deferring signing to a whole new lib that only gets called when some options are set is a better solution than simply updating the signtool that is shipped here?

[thoughtless]

@dopry Can you outline / raise an issue with exactly why you can't use the @electron/windows-sign options to solve this on your side of the build pipeline?

Here are the Microsoft docs explaining why an upgrade is required: https://learn.microsoft.com/en-us/azure/trusted-signing/how-to-signing-integrations

Trusted Signing requires the use of SignTool to sign files on Windows, specifically the version of SignTool.exe that's in the Windows 10 SDK 10.0.2261.755 or later.

Azure Trusted Signing (Microsoft's new, preferred method of signing apps) requires new CLI options (such as /dlib). Attempting to sign with an old version of signtool.exe will fail.

UPDATE: This can be worked around with the optional windowsSign config. For example:

  await electronInstaller.createWindowsInstaller({
    appDirectory: '/tmp/build/my-app-64',
    outputDirectory: '/tmp/build/installer64',
    authors: 'My App Inc.',
    exe: 'myapp.exe',
    windowsSign: {
      signToolPath: process.env.MY_SIGNTOOL_PATH
    }
  });

But given that Azure Trusted Signing is now Microsoft's preferred way, it would really streamline things if signtool.exe were updated and this tool also vendored a copy of Azure.CodeSigning.Dlib.dll. That would make Azure Trusted Signing super easy.

[nikwen]

For everyone trying to get Trusted Signing to work, you can look at https://www.electronforge.io/guides/code-signing/code-signing-windows#using-azure-trusted-signing for a working configuration.

[dopry]

Updating the bundled signtool eliminates the need for the windows-sign package as far as I can tell. I'll give it a try again... Hopefully, the bugs in it were fixed, but it still feels like an over engineered solution to updating the embedded signtool.