Code signing rejected - unnotarized Developer ID

[mattgogerly]

• Version: 20.39.0

• Target: platform=darwin arch=x64 electron=4.1.4

I've generated a Developer ID Application certificate using Xcode and I can see it in login on Keychain. When I run electron_builder I get the following error:

Error: Command failed: spctl --assess --type execute --verbose --ignore-cache --no-cache /Users/mattgogerly/Documents/GitHub/MailBean/frontend/electron_dist/mac/MailBean.app
/Users/mattgogerly/Documents/GitHub/MailBean/frontend/electron_dist/mac/MailBean.app: rejected
source=Unnotarized Developer ID

I can't seem to find anything about unnotarized IDs with electron-builder, hence this issue. Any ideas how to fix?

[martani]

I have the same issue after updating to OSX 10.14.5. This error does not happen on previous versions, notably 10.14.4. Any ideas about what's causing this and how to fix?

[dorokei]

Unfortunately, I also updated to OSX 10.14.5 and have the same problem😭

[martani]

You can use electron-notarize but the afterSign hook is broken on Mac, so this is still an issue. See #3908.

You can also try to notarize the app manually: https://stackoverflow.com/questions/53112078/how-to-upload-dmg-file-for-notarization-in-xcode

[wildcodeman]

I also updated to OSX 10.14.5 and then...😂

Here is my solution:

Edit file node_modules/electron-osx-sign/sign.js, find function verifySignApplicationAsync, comment section below, and every thing goes right!

  // Additionally test Gatekeeper acceptance for darwin platform
  //if (opts.platform === 'darwin' && opts['gatekeeper-assess'] !== false) {
  //  promise = promise
  //    .then(function () {
  //      debuglog('Verifying Gatekeeper acceptance for darwin platform...')
  //      return execFileAsync('spctl', [
  //        '--assess',
  //        '--type', 'execute',
  //        '--verbose',
  //        '--ignore-cache',
  //        '--no-cache',
  //        opts.app
  //      ])
  //    })
  //}

That code looks just test the app files, so remove it should be ok, I don't know why...but that fixed my problem...

[will-stone]

Unfortunately, @wildcodeman's solution doesn't works for me. Well, it allows my app to be packaged but when I release and download, I still get the "app cannot be opened" error. This means the app hadn't really been notarized.

[wagslane]

This is a big problem... @wildcodeman solution definitely wont work for any production app, as it is editing the node modules files directly.

[lordkerwin]

I too now have this issue after doing the update.... -__- not ideal when trying to deploy apps to production...

[KASOGIT]

Does someone found any fix that's acceptable in production ?

[martani]

So I was able to track this a bit. I generated a dmg that's notarized (also tried to notarize the .app before packaging within a dmg but I'm getting the same results):

On macOS 10.14.4:
APP

codesign --verify -vvvv my_app.app
my_app.app: valid on disk
my_app.app: satisfies its Designated Requirement

spctl --assess --type install --context context:primary-signature -v my_app.app
my_app.app: accepted
source=Notarized Developer ID

spctl --assess --type execute --context context:primary-signature -v my_app.app
my_app.app: accepted
source=Notarized Developer ID

spctl --assess --type open --context context:primary-signature -v my_app.app
my_app.app: accepted
source=Developer ID

DMG

codesign --verify -vvvv my_app.dmg
my_app.dmg: valid on disk
my_app.dmg: satisfies its Designated Requirement

spctl --assess --type install --context context:primary-signature -v my_app.dmg
my_app.dmg: accepted
source=Notarized Developer ID

spctl --assess --type execute --context context:primary-signature -v my_app.dmg
my_app.dmg: rejected (the code is valid but does not seem to be an app)

spctl --assess --type open --context context:primary-signature -v my_app.dmg
my_app.dmg: accepted
source=Developer ID

On macOS 10.14.5:
All the results are the same, except for:

spctl --assess --type open --context context:primary-signature -v my_app.app
my_app.dmg: rejected
source=no usable signature

spctl --assess --type open --context context:primary-signature -v my_app.dmg
my_app.dmg: rejected
source=no usable signature

The issue seems to be related to the --type open assessment. The side effect of this is that when a user double clicks the dmg on macOS 10.14.5, they do not have the open to click "open", only a close button! I don't have enough knowledge of how gatekeeper handles this type, but does it indicate that something is missing during the sign process for the dmg?

Note that this is not an issue for the .app itself because the default action after a double click is to execute. And the execute assessment type shows correctly that the app is notarized.

[Kilian]

@martani can you share a screenshot of the message a user sees when they try to open that dmg?

[KASOGIT]

@Kilian That's the one i'm getting

English: "Cannot open "app name" cause apple can't verify that there isn't any malicious soft in it"

[Kilian]

Here's the English text:

Worth noting, if you right-click and open, then you do get the expected buttons.

[Kilian]

On 10.14.5 I tried the same as @martani with a signed + notarized app in a signed+notarized dmg, with the following results:

$ codesign --verify -vvvv Polypane-1.0.0.dmg
Polypane-1.0.0.dmg: valid on disk
Polypane-1.0.0.dmg: satisfies its Designated Requirement

$ spctl --assess --type install --context context:primary-signature -v Polypane-1.0.0.dmg
Polypane-1.0.0.dmg: accepted
source=Notarized Developer ID

$ spctl --assess --type execute --context context:primary-signature -v Polypane-1.0.0.dmg
Polypane-1.0.0.dmg: rejected (the code is valid but does not seem to be an app)

$ spctl --assess --type open --context context:primary-signature -v Polypane-1.0.0.dmg
Polypane-1.0.0.dmg: rejected
source=Unnotarized Developer ID

Where the first three seem as expected, but the third is different and might give more of a clue. I'll look into how electron-builder signs the dmg.