anaisbetts
commented
8 months ago Seems reasonable to me, it is important that Squirrel invoke signtool.exe (i.e. rather than trying to run Squirrel without signing then signing the EXE file after-the-fact) or else certain files will end up not signed correctly like the generated stub files that Squirrel makes
continuous-auth[bot]
This PR enables
@electron/windows-signto "hijack" codesigning within Squirrel. It does so by using@electron/windows-sign's ability to create a customsigntool.exethat's actually a "single executable application" built with Node.js, calling@electron/windows-signunderneath.This, in turn, allows developers to customize their codesigning pipelines - with custom tools, scripts, and even per-file configurations. Now that Windows will only accept EV Codesigning certificates, many developers are faced with codesigning scenarios that are more complex - involving custom tooling, cloud-based solutions, and other shenanigans.
For details on how this all works underneath the hood, check out https://github.com/electron/windows-sign/commit/8b23eaa900b4ca0905699b4fa17ca22246624fdf
Decision to not make this a breaking change
@electron/windows-installeronly requires Node.js >= 8.0.0.@electron/windows-signrequires Node.js >= 16.0.0.@electron/windows-sign's "fake signtool.exe" feature requires Node.js >= 18.0.0, the first version to contain the "single executable" feature.@electron/windows-installer. Instead,@electron/windows-signis an optional dependency - and if it didn't install, we'll throw a useful error only if people are trying to use the newwindowsSignparameter.