Notarization and staple succeeds but app is not able to be verified by Apple

[davidmurdoch]

• Electron-Builder Version:

• Node Version: 18.16.1

• Electron Version: 26.1.0
• Electron Type (current, beta, nightly): current

24.6.3

• Target: mac

trying to open on macOS Montery 12.6.3 (21G419)

Using the built-in "notarize" option in `electron-builder it notarize and stapled successfully, according to the logs (see below), but the app is unable to be opened on Mac.

I can launch the .dmg, which Mac briefly says "Verifying" before successfully opening the installer screen (drag to "Applications"). It then installs, but when I try to open the app it again says "Verifying [...]", but this time for a minute or two, and then fails to open with the message "Ganache" cannot be opened because the developer cannot be verified. macOS cannot verify that this app is free from malware. [...]. (Ganache is the app name).

Logs:

  • signing         file=dist/mac/Ganache.app identityName=Developer ID Application: ConsenSys AG (48XVW22RCG) identityHash=C927DD3B556DC334E4573E643FB6F2F142E5FC5F provisioningProfile=none
2023-09-02T14:51:51.458Z electron-notarize:spawn spawning cmd: xcrun args: [ '--find', 'notarytool' ] opts: {}
2023-09-02T14:51:54.462Z electron-notarize:spawn cmd xcrun terminated with code: 0
2023-09-02T14:51:54.462Z electron-notarize:notarytool starting notarize process for app: /Users/runner/work/ganache-ui/ganache-ui/dist/mac/Ganache.app
2023-09-02T14:51:54.463Z electron-notarize:helpers doing work inside temp dir: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/electron-notarize-5htv5U
2023-09-02T14:51:54.464Z electron-notarize:notarytool zipping application to: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/electron-notarize-5htv5U/Ganache.zip
2023-09-02T14:51:54.464Z electron-notarize:spawn spawning cmd: ditto args: [
  '-c',
  '-k',
  '--sequesterRsrc',
  '--keepParent',
  'Ganache.app',
  '/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/electron-notarize-5htv5U/Ganache.zip'
] opts: { cwd: '/Users/runner/work/ganache-ui/ganache-ui/dist/mac' }
2023-09-02T14:53:33.252Z electron-notarize:spawn cmd ditto terminated with code: 0
2023-09-02T14:53:33.252Z electron-notarize:notarytool zip succeeded, attempting to upload to Apple
2023-09-02T14:53:33.252Z electron-notarize:spawn spawning cmd: xcrun args: [
  'notarytool',
  'submit',
  '/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/electron-notarize-5htv5U/Ganache.zip',
  '--apple-id',
  '*********',
  '--password',
  '*********',
  '--team-id',
  '*********',
  '--wait',
  '--output-format',
  'json'
] opts: {}
2023-09-02T15:19:19.320Z electron-notarize:spawn cmd xcrun terminated with code: 0
2023-09-02T15:19:19.322Z electron-notarize:notarytool notarization success
2023-09-02T15:19:19.323Z electron-notarize:helpers work succeeded
2023-09-02T15:19:19.422Z electron-notarize:staple attempting to staple app: /Users/runner/work/ganache-ui/ganache-ui/dist/mac/Ganache.app
2023-09-02T15:19:19.423Z electron-notarize:spawn spawning cmd: xcrun args: [ 'stapler', 'staple', '-v', 'Ganache.app' ] opts: { cwd: '/Users/runner/work/ganache-ui/ganache-ui/dist/mac' }
2023-09-02T15:19:23.628Z electron-notarize:spawn cmd xcrun terminated with code: 0
2023-09-02T15:19:23.629Z electron-notarize:staple staple succeeded
  • notarization successful
  • building        target=macOS zip arch=x64 file=dist/Ganache-2.7.2-mac.zip
  • building        target=DMG arch=x64 file=dist/Ganache-2.7.2-mac.dmg
  • building block map  blockMapFile=dist/Ganache-2.7.2-mac.zip.blockmap
  • publishing      publisher=Github (owner: trufflesuite, project: ganache-ui, version: 2.7.2)
  • uploading       file=Ganache-2.7.2-mac.zip.blockmap provider=github
  • uploading       file=Ganache-2.7.2-mac.zip provider=github
  • overwrite published file  file=Ganache-2.7.2-mac.zip.blockmap reason=already exists on GitHub
  • overwrite published file  file=Ganache-2.7.2-mac.zip reason=already exists on GitHub
  • copy files      from=/Users/runner/work/ganache-ui/ganache-ui/static/icons/mac/icon.icns to=/Volumes/Ganache 2.7.2/.VolumeIcon.icns isUseHardLinks=false
  • copy files      from=/Users/runner/work/ganache-ui/ganache-ui/build/dmg/background.tiff to=/Volumes/Ganache 2.7.2/.background/background.tiff isUseHardLinks=false
  • execute command  command=sips -g pixelHeight -g pixelWidth /Users/runner/work/ganache-ui/ganache-ui/build/dmg/background.tiff workingDirectory=
  • command executed  executable=sips out=/Users/runner/work/ganache-ui/ganache-ui/build/dmg/background.tiff
  pixelHeight: 498
  pixelWidth: 658

  • building block map  blockMapFile=dist/Ganache-2.7.2-mac.dmg.blockmap
  • uploading       file=Ganache-2.7.2-mac.dmg.blockmap provider=github
  • uploading       file=Ganache-2.7.2-mac.dmg provider=github
  • overwrite published file  file=Ganache-2.7.2-mac.dmg.blockmap reason=already exists on GitHub
  • overwrite published file  file=Ganache-2.7.2-mac.dmg reason=already exists on GitHub
  • overwrite published file  file=latest-mac.yml reason=already exists on GitHub

full logs here: https://github.com/trufflesuite/ganache-ui/actions/runs/6058926364/job/16441511002#step:11:4295

[davidmurdoch]

When I run xcrun stapler validate on the dmg it returns "Ganache-2.7.2-mac.dmg does not have a ticket stapled to it.", When I unzip "Ganache-2.7.2.mac.zip" and run stapler validate on the Ganache.app inside the zip, via xcrun stapler validate Ganache.app it returns "The validation action worked!". However, I still can't open the Ganache.app, as macOS still returns the message about "the developer cannot be verified" when I try.

[confused-Techie]

@davidmurdoch Where you ever able to resolve this issue?

We are seeing the same behavior over on pulsar-edit/pulsar.

With the binaries being produced reporting "Pulsar.app" cannot be opened because the developer cannot be verified.

You can view our a run we are looking at here for GitHub Actions, but otherwise the logs of specifically the signing step show:

Run nick-fields/retry@943e74[29](https://github.com/pulsar-edit/pulsar/actions/runs/6205861939/job/16849479832#step:10:30)17ac94714d2f408a0e8320f2d1fcafcd
yarn run v1.22.19
$ node script/electron-builder.js
  • electron-builder  version=23.3.1 os=21.6.0
  • artifacts will be published if draft release exists  reason=CI detected
  • electron-rebuild not required if you use electron-builder, please consider to remove excess dependency from devDependencies

To ensure your native dependencies are always matched electron version, simply add script `"postinstall": "electron-builder install-app-deps" to your `package.json`
  • skipped dependencies rebuild  reason=npmRebuild is set to false
  • packaging       platform=darwin arch=x64 electron=12.2.3 appOutDir=dist/mac
  • downloading     url=https://github.com/electron/electron/releases/download/v12.2.3/electron-v12.2.3-darwin-x64.zip size=80 MB parts=6
  • downloaded      url=https://github.com/electron/electron/releases/download/v12.2.3/electron-v12.2.3-darwin-x64.zip duration=1.847s
  • signing         file=dist/mac/Pulsar.app identityName=Developer ID Application: Alexander Liu (***) identityHash=FC494904A12136BAD4FAC1E7C85943D7C5E50598 provisioningProfile=none
using notarytool
2023-09-16T07:04:36.349Z electron-notarize notarizing using the new notarytool system
  • building        target=macOS zip arch=x64 file=dist/Pulsar-1.109.202[30](https://github.com/pulsar-edit/pulsar/actions/runs/6205861939/job/16849479832#step:10:31)91606-mac.zip
  • building        target=DMG arch=x64 file=dist/Pulsar-1.109.2023091606.dmg
  • building block map  blockMapFile=dist/Pulsar-1.109.2023091606-mac.zip.blockmap
  • copy files      from=/Users/runner/work/pulsar/pulsar/resources/app-icons/beta.icns to=/Volumes/Pulsar 1.109.2023091606/.VolumeIcon.icns isUseHardLinks=false
  • copy files      from=/Users/runner/work/pulsar/pulsar/node_modules/dmg-builder/templates/background.tiff to=/Volumes/Pulsar 1.109.2023091606/.background/background.tiff isUseHardLinks=false
  • execute command  command=sips -g pixelHeight -g pixelWidth /Users/runner/work/pulsar/pulsar/node_modules/dmg-builder/templates/background.tiff workingDirectory=
  • command executed  executable=sips out=/Users/runner/work/pulsar/pulsar/node_modules/dmg-builder/templates/background.tiff
  pixelHeight: [38](https://github.com/pulsar-edit/pulsar/actions/runs/6205861939/job/16849479832#step:10:39)0
  pixelWidth: 5[40](https://github.com/pulsar-edit/pulsar/actions/runs/6205861939/job/16849479832#step:10:41)

  • building block map  blockMapFile=dist/Pulsar-1.109.2023091606.dmg.blockmap
Built binaries
Done in 1125.75s.
Command completed after 1 attempt(s).

Then just like the OP in this thread reported:

$ xcrun stapler validate /Applications/Pulsar.app/
Processing: /Applications/Pulsar.app
The validate action worked!
$ xcrun stapler validate ~/Downloads/macos-latest\Binaires\ 2\Pulsar-1.109.2023091814.dmg
Processing: ...
Pulsar-1.109.2023091814.dmg does not have a ticket stapled to it.

Additionally, if it helps heres the output to codesign -vvv --deep-verify /Applications/Pulsar.app as well as spctl -a -vvv /Applications/Pulsar.app

Would love to hear back if there's any ideas for troubleshooting this issue, or any way the OP has found to resolve it. Or if there's more information we could provide please ask!

Thanks a ton to anyone that has the time to take a look at this one

[davidmurdoch]

I didn't. 😞

[confused-Techie]

I didn't. 😞

Unfortunate, but maybe we can still help each other.

Pulsar was signing just fine for months, but what seems to have triggered this failure is when we switched from Cirrus CI to GitHub Actions, we thought things we identical, but obviously something has changed.

I looked at the repo you linked, and it looks like you also were switching CI providers around that time maybe? Is it possible there's some Apple specific dependency that's missing somewhere?

[confused-Techie]

I do want to add, just to make it clear.

We have been signing our binaries with no issue for several months, and within the last month, with zero changes to our electron-builder version, or config, this has broken. Yes we did switch to GitHub Actions from Cirrus in this time, but we have confirmed that on our end the setup is identical.

That is of course unless there's some dep missing that came preinstalled on Cirrus and not GHAs, which from what I've read of the docs for electron-builder and electron/notarize seems unlikely.

And while I don't want to be annoying, seeing this issue open for three weeks, and having this issue effect 500+ of our users (According to our last successful signing of Pulsar Intel macOS versions) I hope it's not bad manners to ping @mmaietta and ask if there's any advice, or good places to start troubleshooting. Or anywhere better to ask for assistance.

Would really appreciate any insight into this problem.

[davidmurdoch]

I think Apple changed something. It's happened before to me.

[confused-Techie]

I think Apple changed something. It's happened before to me.

Interesting, sounds like we have to explore that possibility. Ideally it's something that can be changed on our end. Otherwise, if Apple changed something big I would've assumed this functionality would break for everyone, and we wouldn't be the only two citing an issue.

[mmaietta]

Definitely not bad manners, I just have very limited time and also am not too sure how I can help here.

I'm not familiar enough with how notarizing/stapling works to immediately know where to troubleshoot. My best recommendation would be to ping in @electron/notarize project with the logs. electron-builder is just using their notarize project under-the-hood.
Latest release next of electron-builder is up to date with @electron/notarize project v2.1.0

An alternative way to test various versions of @electron/notarize is to integrate it directly within your project in afterSign
In configuration object (pulling from an old project of mine)

afterSign: async (context: builder.AfterPackContext) => {
    if (context.electronPlatformName !== "darwin") {
        return
    }
    const appPath = path.join(context.appOutDir, `${ context.packager.appInfo.productFilename }.app`);
    if (!fs.existsSync(appPath)) {
        throw new Error(`Cannot find MacOS application at: ${ appPath }`);
    }
    if (process.env.APPLE_USERNAME && process.env.APPLE_ONE_TIME_PW) {
        console.log("Notarizing MacOS app using login env vars");
        await notarize({
            appBundleId: "your bundle id",
            appPath: appPath,
            appleId: process.env.APPLE_USERNAME,
            appleIdPassword: process.env.APPLE_ONE_TIME_PW,
            ascProvider: "insert provider if needed"
        }).catch(err => {
            throw err;
        });
        executeShellCommand("spctl", ["-a", "-t", "open", "--context", "context:primary-signature", "-v", appPath])
        console.log("Successfully notarized");
    }
},

[confused-Techie]

@mmaietta I really do appreciate your support here, even if not your primary area of focus.

I'll go ahead and give a try to what you've suggested, but I really appreciate your time!

[confused-Techie]

@davidmurdoch I want to let you know, we just had a successful build on GitHub Actions with electron-builder on macOS, by one weird thing.

We skipped the setup-node action and instead installed it via HomeBrew.
We also did this for git, and python but we are thinking it likely has something to do with NodeJS.

So I hope our workflow may prove to be useful to you as well!

[confused-Techie]

@davidmurdoch Alright, I take this back slightly.

One of our awesome developers was able to find the exact cause, and fix our issues with a single commit diff.

Turns out the solution wasn't removing setup-node it lied within setup-python.

Seems that our version of 3.10 Python (Which we used due to some issues with a specific version of node-gyp we were using, but have since upgraded. But when we bumped to Python 3.11 we were able to resolve our issues!

So I hope this helps you, feel free to take a look at their PR that fixes this here: pulsar-edit/pulsar#743

[mfranzs]

Hey -

We're running into this same issue. For us, the problem is that node-gyp is internally linking to a python3 absolute-path symlink on our build instance.

You can run syspolicy_check distribution YourAppName.app to see the bad file.

We're trying to delete this bad symlink to see if that fixes the issue. Not sure if it will work yet, but it sounds similar to what you found!

[DeeDeeG]

@mfranzs, looks like you're running into nodejs/node-gyp#2713.

This symlinking behavior was introduced with only good intentions .......... (by me, sorry!) in node-gyp 9.1.0, and a fix has landed on node-gyp main branch since then but hasn't been released in any new tagged version of node-gyp just yet... [UPDATE: It's included in node-gyp 10, which is in npm 10.2.2 or newer.]

The solution is to use older node-gyp [UPDATE: or node-gyp 10 or newer], or use the revision of node-gyp straight from its main branch until a newer release is put out...

Most people get node-gyp bundled with npm, so your easiest point of control over this is to use a copy of npm that bundles node-gyp older than 9.1.0... So, based on the changes in npm's package.json when the node-gyp version was bumped... (blame view) You can try downgrading npm to 8.16.0 or older, and see if that makes the problem go away?

[UPDATE: Or upgrade to npm 10.2.2 or newer.]

And longer-term, I really hope node-gyp puts out a newer version and npm adopts it, soon! [UPDATE: Done!]

EDIT: I see you commented on the pending release PR over at node-gyp repo. I guess this info isn't news to you, then. And once again, sorry for not foreseeing the breakage the symlinking would cause.

[davidmurdoch]

@DeeDeeG. Downgrading to npm@8.16.0 worked! It broke my windows build though (npm ci now fails), so I have to conditionally downgrade based on the OS.

[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.

[vitto32]

Is upgrading to npm 10.2.2 working for someone? I still can't get it work

[DeeDeeG]

@vitto32 there were two vaguely related issues discussed in this thread.

• Apple doesn't like you symlinking to outside of the signed files from inside the signed files. Updating to npm 10+, or downgrading to npm 8.16.0/older, should fix this.
• The main issue this thread was opened for, Apple lets you sign and notarize an app but still warns users upon opening the app, as if it's unsigned or the signing is invalid or something.
  • No-one in this thread is totally sure why this happens, but changing the versions of your build tools/dependencies, such as using a different Python version or npm version might help?? I wish I knew more about this issue, but people are just trying things and hoping they work, honestly.

[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.