feat(Code Signing)

[codekiln]

I've implemented support for automated windows authenticode code signing and mac codesign signing in a private fork of nwjs-builder-phoenix. In windows this also includes signing the generated uninstaller as well.

I see that code signing is listed as a TODO in the README. Would you be amenable to a PR adding windows code signing?

[evshiron]

Sorry I haven't been around for quite some time. It's only listed there and I didn't start working on it.
And yes, a PR is much appreciated.

[BlaineEhrhart]

@codekiln Any chance you still have that code laying around? I checked your public repo I don't see these modifications. I know you said they are in a private repo, any chance of pulling those changes out?

@evshiron Is there a decent workaround for this at the moment? This is my first time signing an application. I know I need to sign the installer and I assume I also need to sign the application itself and finally like @codekiln mentions above that signing the uninstaller.

[codekiln]

@bladesling I currently have a private fork in bitbucket with signing implemented for both mac and windows, but don't quite have time to work it up into a proper PR. After July 21st, I can move the fork to github and PR it, but it may be some time before I have the time to re-ensure everything is working great in both environments and pull in any changes that have been merged in the mean time. No promises, but there's a chance!

[BlaineEhrhart]

@codekiln I would greatly appreciate it! If you can't find the time maybe you can just copy the repo to github and I can attempt a PR. I can be patient for a bit.

Thanks!

[codekiln]

@bladesling @evshiron I've added a PR here: #122. I've compiled an application for my company on both Mac and Windows using this code. It's proprietary code, so I can't publish the sample application, but hopefully this will get the ball rolling.

It's a larger change as I had to subclass the nsis configs for windows. Everything has been running in production for 9 months or so.

[BlaineEhrhart]

I've had some time today to set it up on my side and test in windows.

• The build.win.productName can not have spaces in it as the arguments get split up incorrectly when signing
• Along the same lines as above, build.win.cliArgs arguments have spaces in them either and doesn't support quotes to keep items a single argument

After working around these couple things I got a working build. I haven't had time yet to test the .env file which I would want to use. But so far its good. It signed the uninstaller, exe, dlls, and the installer.

I'll test mac out when I get my hands on one to test with.

Thanks @codekiln this is very helpful!

[BlaineEhrhart]

An update to the last message. I've had a little more time to test. Things are looking better.

First, the build.win.productName can have spaces. It was my second issue causing the problem and in my haste I didn't check for that as well.

Second the .env file solved my second issue.

Example package.json build.win section

      "signing": {
        "cliArgsVarsFile": ".env",
        "signtoolPath": "C:\\Program Files (x86)\\Windows Kits\\8.1\\bin\\x64\\signtool.exe",
        "cliArgs": "sign /debug /f ${CERTIFICATE_FILE} /p ${CERTIFICATE_PASSWORD} /tr http://timestamp.digicert.com /td sha256 /fd sha256 /v"
      }

The important things to note is that I took the items with spaces in them and moved them into the .env file. Initially I thought the env file would be used to set all the signing options but this is pretty slick too.

CERTIFICATE_PASSWORD=YOUR_PASSWORD_HERE
CERTIFICATE_FILE="C:\Some Spaced Folder\certificate.p12"

Other notes for the .env file and how it correlates that only the cliArgs property so you can't use it in the signtoolPath which might help building on multiple machines but that isn't required. I'm a happy camper.

To fix the space issue on the args if someone didn't want to use the env you could use something like https://github.com/mccormicka/string-argv or just write the regular expression. But not exactly needed now that there is a workaround.

Hopefully @evshiron comes around and sees this. Until then I forked from your repo and will wait to see what @evshiron wants done and if he wants help with this pull request in some way.