Missing signature on Squirrel ExecutionStub

[t3chguy]

element-hq/element-desktop#2204 for context

Missing sig on the execution stub e.g.

Broken:

Good:

(same was true for 1.11.94 but we had to pull the package due to Node N-API issues)

Good in 26.0.1
Bad in 26.0.8
Still bad in 26.0.11

[mmaietta]

@beyondkmp can you please take a look at this when you have a chance?

[beyondkmp]

Based on the analysis of Squirrel Windows source code, when createExecutableStubForExe is executed, WriteZipToSetup writes information to the file, essentially creating a new file, which invalidates the original signature.

https://github.com/Squirrel/Squirrel.Windows/blob/51f5e2cb01add79280a53d51e8d0cfa20f8c9f9f/src/Update/Program.cs#L633-L647

It seems Windows Installer doesn't support hookFunction(electron/windows-installer#548), and electron-builder can't re-sign the newly generated stubExe file. Currently, there are three potential solutions:

1. Could electron-builder's sign module generate a hookModulePath js file? This seems challenging as it requires reading configurations, and the implementation approach isn't clear yet.

2. Add hookModulePath configuration for users to write their own. This is typically needed only for special requirements. Previous signtools' csc/csc_password is supported, and Windows Installer supports these parameters or custom signtools.

https://github.com/electron/windows-installer/blob/e722a519f8625c939087de2602b2b5b594886bc4/src/index.ts#L212-L228

3. Abandon Windows Installer and implement everything using the original method.

@mmaietta Which solution do you think is better?

[t3chguy]

Add hookModulePath configuration for users to write their own. This is typically needed only for special requirements. Previous signtools' csc/csc_password is supported, and Windows Installer supports these parameters or custom signtools.

Empirically this did not work for me, given I'm just using the system signtool.exe +

and it was failing as you previously investigated

[beyondkmp]

I've come up with a solution. Apply a patch to the Squirrel Windows source code. For the existing stub exe files, don't generate them anymore. Then, a new stub exe can be generated in Electron Builder and signed. The version of Squirrel Windows 2 has been around for nearly five years. In fact, its develop branch has been constantly updated and many bugs have been fixed. So we can take this opportunity to directly generate and use the latest version.

[beyondkmp]

I've already compiled Squirrel Windows locally. I'll trigger a release on GitHub Actions, so there won't be any security concerns either.

[beyondkmp]

Squirrel/Squirrel.Windows#1903

[beyondkmp]

@t3chguy #8959 I've tested it locally and it works fine. When you have time, could you help test the element-desktop with the PR again?

[t3chguy]

Sure thing @beyondkmp - started tests in element-hq/element-desktop#2211 - will report back in the PR

[mmaietta]

I've already compiled Squirrel Windows locally. I'll trigger a release on GitHub Actions, so there won't be any security concerns either.

@beyondkmp , what do you mean by this?

[beyondkmp]

I've already compiled Squirrel Windows locally. I'll trigger a release on GitHub Actions, so there won't be any security concerns either.

@beyondkmp , what do you mean by this?

I mean these files are all generated by GitHub Actions, directly compiled from source code. They are not compiled on my local machine, so there's no need to worry about any backdoors being injected.

These vendor files are copied from the GitHub Actions workflow at https://github.com/beyondkmp/Squirrel.Windows/actions/runs/13871759240/job/38819263248 and the other files(like 7zip,nuget) are copiled from https://github.com/electron/windows-installer/tree/main/vendor.

https://github.com/Squirrel/Squirrel.Windows/pull/1903/files
The code changes for Squirrel Windows are located here.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[mmaietta]

I mean these files are all generated by GitHub Actions, directly compiled from source code. They are not compiled on my local machine, so there's no need to worry about any backdoors being injected.

I agree, but for fork repos, we don't track releases by commit hash, no? So that could mean that new changes (for any fork in general) could be pushed and lead to a supply-chain vulnerability. All vendor assets also need to be on-demand downloads, not committed directly to this project (which is the use case that electron-builder-binaries provides for)