Previous build on Windows signed with an apple cert, now I can't update

[jsheffers]

Somehow the previous version of my app got built and code signed with my apple cert. It also seems to have defaulted to verifyUpdateCodeSignature as I never explicitly set this. I tried creating a new build with this property disabled, but I think the damage is already done.

Is there a way to get out of this failed update loop without having a valid cert for the new build and without having the user download the new build manually? We're talking about 1,000 app distribution with no easy way to have everyone download the app/s manually. Also, how did this happen? I've never enabled this property to force verification?

electron-builder: 26.0.12
electron-updater: 6.6.2

[mmaietta]

Wait what? How did the mac app get signed with an incorrect cert?

1. Didn't realize non-mac certs could still sign a .app on mac using codesign via electron/osx-sign npm package
2. How are you providing the windows cert to electron-builder during mac builds? This sounds like a local setup issue in your electron-builder config or env setup
3. verifyUpdateCodeSignature is explicitly a Windows-specific function. Can you check what app is being downloaded from the update server? I've never heard of this issue before

[jsheffers]

Yes, this is definitely a config issue on my end. For some background, I was building locally on my mac using this package to build DMG's and NSIS installers for our apps. The apple cert was in my keychain so code signing worked just fine for the apple builds.

We finally moved our process to gitlab pipelines and are using two mac minis as runners. When I did this process we moved from the apple cert being in a keychain to setting the CSC_LINK & CSC_KEY_PASSWORD envs. I was unaware that this would cause the Windows builds to be signed with the same cert.

What I don't understand is why the installer is forcing the code verification that I never turned on? Was it because the windows installers got mistakenly signed so electron-updater just started expecting a signed version for updates? I'm going to explicitly turn off verifyUpdateCodeSignature, but I still don't understand how this happened. This also seems like a setting that should be off by default...

Now we're going to have to manually update 1,000 machines... :(

[mmaietta]

Sorry, maybe I misunderstood. The Windows build was signed with the Apple certificate? I also didn't realize that was possible. How did signtool pick the correct certificate and publisher details?

verifyUpdateCodeSignature is always enabled for electron-updater, but is allowed to be overridden if explicitly desiring to add additional verification methods. I would highly advise against removing signature validation. That being said, I'm really sorry to hear of your situation.

[jsheffers]

I'm not dealing with two different certificates here. We were not attempting to code sign the Windows installer at all.

Here are the steps to reproduce

1. Export apple cert
2. Fill in CSC_LINK and CSC_KEY_PASSWORD (base64 of the cert).
3. Set those vars into the environment
4. Run electron-builder with the --mac and --win flag (BUILD ON A MAC)

Electron builder will sign the Mac app and the Windows installer with the same cert (it'll be invalid for Windows and break the updater).

---

How we've done things in the past

For years, and I mean literally years (5-6), we've been building these installers (DMG, NSIS) without issue. The DMG has always been signed via the apple cert (keychain automatically) and the NSIS installer has not been signed at all. We've been through thousands of auto-updates without a code signed NSIS installer and it NEVER rejected verification (nor did we explicitly turn off verification). Any idea on why all of the sudden it would start enforcing this?

In summary

1. Why would electron-builder sign the Windows installers with an invalid cert for the platform?
2. Why all of the sudden did electron-updater start requiring verifications when the cert was invalid, but never rejected it when it wasn't signed at all?

Thank you for your time

[jsheffers]

After more testing today I can give you a concrete example.

1. Build the Windows installer without a certificate and without setting verifyUpdateCodeSignature (which defaults to true).
2. Publish it to the update server.
3. Build another exactly the same and increase the version number.

This creates a successful auto-update and the users get the new version. This makes no sense to me because verifyUpdateCodeSignature defaults to true? If it is true, why is it allowing an update without a digital signing at all? I assume it's because that property only becomes relevant when the installers have a digital signature, but it does contribute to the confusion on this topic.

[mmaietta]

This is problematic and I need to investigate this - seems like a critical issue but I don't know where the logic would have changed (off the top of my head)

Would you be willing to provide a minimum repro repo for this? I think I need to reconfigure my local update server env since it broke with latest macos update for some reason.

[mmaietta]

For years, and I mean literally years (5-6), we've been building these installers (DMG, NSIS) without issue.

What version did you update electron-builder from to 26.0.12? This might help me bisect as well

[jsheffers]

I'll see what I can do about a repro.

Previous versions
electron-builder – 24.13.3
electron-updater – 6.3.9

Keep in mind when I did the latest upgrade from the versions above, that's when we changed the way we were setting the ENV's (putting CSC_LINK & CSC_KEY_PASSWORD into our pipeline as vars instead of the local machine) so it's possible this has existed prior to this version.

[mmaietta]

A repro repo would be really helpful. I just tested locally with a script that sets CSC_LINK and CSC_KEY_PASSWORD and was unable to reproduce.
Can you run with DEBUG=electron-builder env var set and report back with the console logs? Also might be worth adding win.forceCodeSigning = true to your config too.

From my side, signing the .app is successful, then electron-builder logs to sign the .exe and then skips it.

  • signing with signtool.exe  path=dist/win-arm64-unpacked/electron-quick-start-typescript.exe
  • no signing info identified, signing is skipped  signHook=false cscInfo=null
  ⨯ App is not signed and "forceCodeSigning" is set to true, please ensure that code signing configuration is correct, please see https://electron.build/code-signing

The code path seems to only allow WIN_CSC_LINK as well

electron-builder/packages/app-builder-lib/src/codeSign/windowsSignToolManager.ts

Lines 140 to 146 in 20e3f28

	const cscLink = this.packager.getCscLink("WIN_CSC_LINK")
	if (cscLink == null || cscLink === "") {
	return Promise.resolve(null)
	}
	return (
	importCertificate(cscLink, this.packager.info.tempDirManager, this.packager.projectDir)

[jsheffers]

I will run this today and get back to you. In the meantime, here is the exact pipeline output of the problematic build.

[mmaietta]

Hmmm. Wondering if there's something unique about your cert setup. Does it contain anything other than the Apple Authority and your Developer ID Application?

Also, thank you for this report and for your collaboration on this - your consistent replies are truly appreciated.

[jsheffers]

Here is the extent of the config.

productName: My App
appId: app.myapp.app
artifactName: ${productName}-installer.${ext}
files: src/**/dist/**

directories:
  output: apps/${version}/myapp

win:
  target: nsis
  icon: icons/ico/logo.ico

mac:
  target:
    - target: default
      arch: arm64
  icon: icons/icns/logo.icns
  hardenedRuntime: true
  gatekeeperAssess: false
  entitlements: entitlements.mac.plist
  entitlementsInherit: entitlements.mac.plist

dmg:
  title: ${productName}

nsis:
  include: installers/myapp-installer.nsh
  deleteAppDataOnUninstall: true

publish:
  provider: generic
  url: https://example.com/apps/myapp
  channel: latest

How we call it:

export CSC_LINK="base64 encoded apple cert"
export CSC_KEY_PASSWORD="password"
electron-builder --mac --win --config $config_file -c.extraMetadata.name="$APP_NAME"

Some of the debugging output, I would need your input on what to actually provide you. There are 4,000+ lines of output.

  • signing with signtool.exe  path=apps/62.0.0/folder/win-unpacked/App.exe
  • signing         file=apps/62.0.0/folder/win-unpacked/App.exe certificateFile=/private/var/folders/yg/pcdzq2l95wl6rws_w75jj2180000gn/T/t-7EGrks/7.p12
  • spawning        command=/Users/gitlabrunner/builds/F_1rCUg5j/0/company/node_modules/app-builder-bin/mac/app-builder_amd64 download-artifact --name winCodeSign
  • found existing  path=/Users/gitlabrunner/Library/Caches/electron-builder/winCodeSign/winCodeSign-2.6.0
  • exited          command=app-builder_amd64 code=0 pid=22761 out=/Users/gitlabrunner/Library/Caches/electron-builder/winCodeSign/winCodeSign-2.6.0
  • executing       file=/Users/gitlabrunner/Library/Caches/electron-builder/winCodeSign/winCodeSign-2.6.0/darwin/10.12/osslsigncode args=-in /Users/gitlabrunner/builds/F_1rCUg5j/0/company/apps/62.0.0/folder/win-unpacked/App.exe -out /Users/gitlabrunner/builds/F_1rCUg5j/0/company/apps/62.0.0/folder/win-unpacked/App-signed-sha1.exe -t http://timestamp.digicert.com -pkcs12 /private/var/folders/yg/pcdzq2l95wl6rws_w75jj2180000gn/T/t-7EGrks/7.p12 -h sha1 -n App -pass a90beca7e498ddd6de5deeb17fd10d836cd35b25049d7713eaef493872feff5f (sha256 hash) env={
  "DYLD_LIBRARY_PATH": "/Users/gitlabrunner/Library/Caches/electron-builder/winCodeSign/winCodeSign-2.6.0/darwin/10.12/lib"
}