Digital signature of Windows executables

[eliandoran]

Discussed in https://github.com/orgs/TriliumNext/discussions/9

^{Originally posted by deajan February 15, 2024}
We've already discussed this in one of the issues in zadam's repo.

Windows executables should be signed in order to avoid smartscreen screens.
One solution would be to buy a EV certificate (about $270/year) for the organization, and have one member keep the physical token.

Other solution is I can offer my company's code signing certificate services, but this would mean that I'd need to sign the windows executables (new code signing certificates require physical tokens). Of course, I vouch for my company's certificate ^^

---

See zadam/trilium#4411 for details.

[deajan]

@eliandoran Just ping me whenever you need to sign something.
The EV cert I'm using is solely used to sign my own opensource software, so I'll be happy if my investment is used more broadly ;)

[eliandoran]

@deajan , the time has come.

If I remember correctly, the main roadblock was the fact that the certificate signing requires manual intervention.

Do you think there's any chance we could integrate it with the CI? Something like have the CI wait for you to sign it locally on your device? 🤔

The idea is that I would like the CI to handle the entire build, signing and release process.

[deajan]

@eliandoran Glad the time has come ;)

To be honest, unless the windows CI is hosted by the org, I have no clue how to attach the USB key to it.
Also, everytime it's used, it asks for a password, so I don't see any good way to automatize this.

The only thing I can do is signing when artifacts are created, manually, and provide them on a ftp/http server for you guys to upload. I can pledge to do this quickly (less than 24h generally) and for all official windows releases.

This can be done until the org has enough money to buy a EV certificate (with the same limitations btw).

[eliandoran]

@deajan , there might be some black magic involved but I think it's doable. Could you please have a look at: https://medium.com/@joshualipson/ev-code-certificates-automated-builds-for-windows-6100fb8e8be6

It would involve setting up the device you are using for signing right now as a GitHub Runner. If this is something that you'd like or can do, it would be great. Maybe your other projects could benefit from the same automation as well.

[deajan]

@eliandoran Yes, that's basically what I meant, the CI needs to be hosted by the org instead of github.
The findings on the article is interesting because it can be password-less.

I can setup a Windows VM, attach the EV USB stick to it via usb passthru, and add the github runner executable to it.
To keep things safe, the machine would download the actions script, which would then request the password from another file/registry.

Do you use standard github-action runners or custom build ones today ?

I can setup a github runner this weekend, but in order to do so, I'd need to get temporary write permissions on the org, in order to shift the CI runner from github to that one.

[eliandoran]

@deajan , sounds great.

I've given you temporary full access to the org. Feel free to add a org-level runner here: https://github.com/organizations/TriliumNext/settings/actions/runners

[deajan]

@eliandoran Sorry for the delay, I'm trying to setup a Windows VM with USB passthru on my current KVM stack. Takes more time than I hoped to get things right.

[deajan]

@eliandoran So today I've setup automatic EV signing for my projects. Your link needed a bit more research, but I managed to modify my signing code here

Since keeping the EV password secure is quite important, I've managed to write a bit of code which AES encrypts the EV cert data here

I've tested this code against my personal projects that require signature.
Now that I'm done, I'll implement this on the github runner.
Again, sorry for the delay.

[deajan]

Runner is now registered at TriliumNext org.
Would you mind walking me through https://github.com/TriliumNext/Notes/blob/develop/.github/workflows/release.yml ?
I'm not sure where the zip files are generated, but I definitly need to unzip them in order to be able to sign the executables.

[eliandoran]

Hi, @deajan ,

This is great news!

The release CI script doesn't actually do much. It's a matrix which goes through all the platforms, including Windows 64.
Each build is actually an installation of dependencies, followed by running npm run make-electron. The resulting artifacts are either uploaded to GitHub Actions as artifacts, or to a release. The packaging (.zip, .exe) is handled automatically.

The build itself is handled using Electron Forge, which makes distributing Electron-based applications quite simple, including with the Squirrel installer for Windows and .dmg images for macOS.

I think the secret lies not within modifying the release script, but modifying the Electron Forge configuration. In our case the config file is in /forge.config.cjs.

It appears that there is an option to trigger an external tool to be able to sign the application, as mentioned in electron/forge#3617.

Let me know if you need more information and I'll happily provide them. Good luck!

[deajan]

@eliandoran I am truly sorry for the delay. I pledge to make this happen until the end of the year (lacking free time).

[eliandoran]

@deajan ,

I would really love to have signed builds early January. I know how difficult it is to find the time.

There's always the option of buying an EV on our own, provided we gather enough donations to afford it year after year.

[deajan]

Currently working on it. Give me until this weekend. If not done, I pledge to donate enough for you guys to buy a code signing cert ;)

[eliandoran]

@deajan , no worries.

[deajan]

@eliandoran So this made much more headaches than I hoped for ^^

Passing the USB token to thge VM was the easy part.

There are some rules that make signing executables a bit complicated. For instance, one cannot use a RDP connection to a Windows Server, since it will render the EV Token disabled, without any good explanation.

Also, having an automatic signer can make the EV Token unusable if a wrong password is given three times, so I had to implement a sort of safeguard (if an error log file is present, nothing will be signed until the error log file is cleared manually).

Also, I did have fun understanding that there are Github Action runners at org and repo level (so I thought mine disappeared until looking at org level).

Anyway, I've setup a github runner at the TriliumNext org level, that only allows to run on notes repo.
Since notes repo is public, this creates a security risk.
So I've isolated the VM that runs the github actions script.
There's a single binary that can sign any windows PE executable (and perhaps arm executables, but I cannot test that easily).

Binary has to be run like this:

C:\ev_signer_trilium\ev_signer_trilium.exe --executable c:\path\to\my\file\to\sign.exe

and will output exit code 0 upon good signature, and 1 on any other case.
There is a new branch in notes repo, called ev-signature with a workflow that runs on one of my gh runners.
Would you mind modifying the forge script to call that tool ? I don't speak java/typescript myself.

Also, for security reasons, only release versions should be signed at the end, so you'll have to change the on push action to filter by tag again once you're done testing.

Let me know if you need anything else.