Electron-builder: Notarize app for macOS

[pashvin]

Is there any way to notarize app using electron builder?
Looks like Apple is going to force it soon. see link below
https://developer.apple.com/news/?id=04102019a

There is one npm module available but it will be nice this is supported by electron-builder.
https://github.com/electron-userland/electron-notarize

[martani]

I have users on OSX 10.14.5 reporting that the electron app can't be opened anymore.

Running spctl -a -t open --context context:primary-signature -v <pathToDMG> returns the following error:

Downloads/<pathToDMG>.dmg: rejected
source=Unnotarized Developer ID

It would be great if we have some option to notarize the app with electron-builder.

[Kilian]

ticket #3908 mentions running electron-notarize yourself in the afterAllArtifactBuild step, but probably due to timing, this interferes with the publish step so is less than ideal. Having this integrated would be super helpful.

[Kilian]

Also, this is blocked by #3504, otherwise you could roll your own with electron-notarize in the afterSign(not in the afterAllArtifactBuild step).

[lane-c-wagner]

Yeah this is a big issue :( all our Mac installs started breaking. Trying to figure out how we can do notarization using electron builder on a ci server (Travis) if anyone figures it out let me know!

[Kilian]

I have a fix in #3912, once that lands you can call electron-notarize in the afterSign step and everthing works as expected. I'll write a blogpost about it once it's merged in/published :)

[lane-c-wagner]

I have a fix in #3912, once that lands you can call electron-notarize in the afterSign step and everthing works as expected. I'll write a blogpost about it once it's merged in/published :)

You're a a hero, I'm excited.

[Kilian]

There's a few more things that need to happen, it seems. The DMG is also signed by electron-builder and anything that gets signed needs to be notarized or it won't be allowed to install. So we need one of two options:

• A setting to turn off signing the DMG. This is less than ideal, but workable. This creates an unsigned, un-notarized DMG that installs a signed and notarized app. You'll likely get the unknown developer message.
• An extra hook called after creating the dmg but before any of the electron-updater files (blockmap, latest-mac.yml) are created. The notarization process "staples" the dmg so the file changes, so it needs to run before any of the updater files are created. Instead of this, electron-notarize could add a setting where it doesn't staple the file after notarizing. This means a computer needs internet access to validate a notarization, but also means that the dmg does not change, and you can run notarize _after_ all the update files have been created.

[Kilian]

@develar is this something you could help coordinate?

[develar]

electron-builder should use electron-notarize under the hood and user should not configure some hooks.

[develar]

update files

For DMG currently updates files are not used by electron-updater.

[Kilian]

That would be the best! It also means when the afterSign fix is released, we have a complete story for notarizing (albeit manually)

On 25 May 2019, at 10:23, Vladimir Krivosheev [e-mail] wrote:

electron-builder should use electron-notarize under the hood and user should not configure some hooks.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[Kilian]

We're tracking an issue in #3828 that's preventing regular users from installing from an electron-builder generated dmg even though it is notarized.

[Kilian]

The signing and notarizing of the app works with 20.42.0 using electron-notarize and (on macos 10.14.5) disabling electron-osx-sign's gatekeeper assessment. The signing and notarizing the dmg after its creation also works. If you check spctl -a -v for the app, and for the app inside the dmg, then the app is accepted and signed by a notarized developer id, so that all works as it should.

However, the dmg itself can only be opened by holding cmd, or right-clicking and selecting open. Additionally, users are greeted with an ominous message about malicious software.

For Google-ability, this is the text in the image:

"Appname.dmg" can't be opened because Apple cannot check it for malicious software.

This software needs to be updated. Contact the developer for more information.

This is less than ideal. @martani found out that it's the "open" type assessment of the dmg is not being notarized, and we suspect that's the issue.

[Kilian]

Solution found

When the DMG is not codesigned and not notarized, but the app inside it is, Gatekeeper accepts it.

So for the complete story regarding notarization with electron-builder we need two additional things:

1. it needs to disable the gatekeeper assessment when calling electron-osx-sign
2. the code that signs DMGs in dmg-builder should be removed (or there should be an option to disable it
3. _bonus: implement electron-notarize as a new step after sign._

@develar I'll make a PR for point 1 and 2.

[martani]

Awesome, thanks @Kilian! I can confirm your solution is working as expected.

[Kilian]

And here's the guide on how to Notarize your app using electron-builder: https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/

[zaherg]

@Kilian thanks for the post, just a small note about dotenv you can have a file called electron-builder.env which will be read by electron-builder automatically and the values within it can be used automatically within your aftersign script

[puresick]

@Kilian Thanks for the PR and the blogpost summarizing this.
There seems to be a bug with setting the { dmg: { sign: false } } option explicitly, because it gives me an error that this is an invalid configuration (with 20.43.0):

Error: Configuration is invalid.
 - configuration.dmg should be one of these:
   object { artifactName?, background?, backgroundColor?, contents?, format?, icon?, iconSize?, iconTextSize?, internetEnabled?, publish?, title?, window? } | {
     "type": "null"
   }
   macOS DMG options.

   Details:
    * configuration.dmg has an unknown property 'sign'. These properties are valid:
      object { artifactName?, background?, backgroundColor?, contents?, format?, icon?, iconSize?, iconTextSize?, internetEnabled?, publish?, title?, window? }
    * configuration.dmg should be null:
      {
        "type": "null"
      }

[Kilian]

Hmm, it should be there: https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/options/macOptions.ts#L192 @develar any idea?

[will-stone]

@Kilian Thanks for the blog post. May I suggest that you change the recommendation of storing the appleIdPassword from an env var to keychain? It wouldn't take much for someone to write malicious code into a package that dumps all of your environment variables and uploads them to a malicious actor. Using keychain will prompt the user to unlock it when running the notarize script, and at least there's some protection there before it's exposed.

[Kilian]

@will-stone Thanks, I've added a reference to https://github.com/electron-userland/electron-notarize#safety-when-using-appleidpassword

[BertholetDamien]

Thanks @Kilian for the guide ! It's really good.

Just a little thing, there is a little mistake into the notarize.js script (you declare electronPlatformName after using it).

[vkolova]

@Kilian , great guide! We tried it, but it didn't work for us.
We got as far as *** Error: To use this application, you must first sign in to iTunes Connect and sign the relevant contracts. and then we got stuck, because the developer is signed in in Application Launcher in Xcode, but we don't want to upload and release our application in the App Store (as the Launcher prompts us?).

We also tried disabling dmg signing and tried with no notarization, but then still get the unverified developer message. We used [email protected]. Any ideas on where to go from this?

[lane-c-wagner]

This is a relatively new problem. It means you need to sign into your
developer account with apple and accept all their new terms and agreements

On Fri, Jun 28, 2019, 7:02 AM Veselina Kolova [e-mail]
wrote:

@Kilian https://github.com/Kilian , great guide! We tried it, but it
didn't work for us.
We got as far as * Error: To use this application, you must first sign
in to iTunes Connect and sign the relevant contracts. and then we got
stuck, because the developer is signed in in Application Launcher in Xcode,
but we don't want to upload and release our application in the App Store
(as the Launcher prompts us?).

We also tried disabling dmg signing and tried with no notarization, but
then still get the unverified developer message. We used
[email protected]. Any ideas on where to go from this?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/electron-userland/electron-builder/issues/3870?email_source=notifications&email_token=AFHZKVNDH56HVS6GFJJHRM3P4YDWLA5CNFSM4HJ65SN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2AJRA#issuecomment-506725572,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFHZKVPYBBGU4HRE5KGM4E3P4YDWLANCNFSM4HJ65SNQ
.

[raymondjacobson]

fwiw -if you land here, you can get all of these by logging in to
http://itunesconnect.apple.com

[develar]

In addition to https://github.com/electron-userland/electron-builder/issues/3383#issuecomment-508834441 another changes in upcoming electron-builder 21.0.10:

• no need to specify entitlementsInherits and entitlements — it is by default to what stated in the https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/ article. If you are aware of a better defaults, please comment.
• macOS High Sierra 10.13.6 is required unconditionally. Old version of macOS is not supported anymore.

[develar]

@Kilian 21.0.10 is released, will be great if you will find time to update your article.

[julienma]

macOS High Sierra 10.13.6 is required unconditionally. Old version of macOS is not supported anymore.

@develar do you mean that 10.13.6 is required to notarize the app (and said app will work on earlier macOS versions), or that once notarized, an app requires at least 10.13.6?

---

edit: oh ok, got the answer:

Please note — macOS High Sierra 10.13.6 is required now to sign macOS application.

[jwheare]

@develar:

If you are aware of a better defaults, please comment.

3940 has some extra entitlements that appear to be needed for additional executables to work.

[steffanhalv]

I followed your guide, but could not get this to work.
The app is successfully beeing notarized, but after uploading & downloading + launch I get this error both for the dmg and mac.zip file through autoupdater:

Error on launch:

Process:               AppName [27002]
Path:                  /Applications/AppName.app/Contents/MacOS/AppName
Identifier:            com.appname.AppName
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           AppName [27002]
User ID:               501

Date/Time:             2019-07-18 15:32:57.651 +0200
OS Version:            Mac OS X 10.14.5 (18F132)
Report Version:        12
Anonymous UUID:        5E992DCE-9E0C-9346-5741-904D729392C7


Time Awake Since Boot: 3500 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (Code Signature Invalid)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x1

kernel messages:

VM Regions Near 0 (cr2):
--> 
    __TEXT                 0000000108273000-000000010829c000 [  164K] r-x/rwx SM=COW  

Thread 0 Crashed:
0                                   0x000000010e467000 _dyld_start + 0

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000000  rcx: 0x0000000000000000  rdx: 0x0000000000000000
  rdi: 0x0000000000000000  rsi: 0x0000000000000000  rbp: 0x0000000000000000  rsp: 0x00007ffee798cb90
   r8: 0x0000000000000000   r9: 0x0000000000000000  r10: 0x0000000000000000  r11: 0x0000000000000000
  r12: 0x0000000000000000  r13: 0x0000000000000000  r14: 0x0000000000000000  r15: 0x0000000000000000
  rip: 0x000000010e467000  rfl: 0x0000000000000200  cr2: 0x0000000000000000

Logical CPU:     0
Error Code:      0x00000000
Trap Number:     0


Binary Images:
       0x108273000 -        0x10829bff7 + (0) <3788637B-0A53-3737-B3B6-C827ABF3E314> 
       0x10e466000 -        0x10e4d06ef + (655.1.1) <CE635DB2-D47E-3C05-A0A3-6BD982E7E750> 

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 116624
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=776K resident=0K(0%) swapped_out_or_unallocated=776K(100%)
Writable regions: Total=8404K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=8404K(100%)

                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
STACK GUARD                       56.0M        1 
Stack                             8192K        1 
__DATA                             244K        4 
__LINKEDIT                         184K        2 
__TEXT                             592K        2 
shared memory                        8K        2 
===========                     =======  ======= 
TOTAL                             65.0M       12 

Model: Macmini6,2, BootROM 278.0.0.0.0, 4 processors, Intel Core i7, 2,6 GHz, 12 GB, SMC 2.8f1
Graphics: kHW_IntelHD4000Item, Intel HD Graphics 4000, spdisplays_builtin
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x859B, 0x43543130323436344246313630422E433136
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80CE, 0x4D34373142353137334442302D594B302020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x10E), Broadcom BCM43xx 1.0 (7.21.190.33 AirPortDriverBrcm4360-1325.2)
Bluetooth: Version 6.0.12f1, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: APPLE SSD SM256E, 251 GB
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: Keyboard Hub
USB Device: USB Receiver
USB Device: Apple Keyboard
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: Hub
USB Device: IR Receiver
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: USB 3.0 Bus
USB Device: Hub
USB Device: Hub
USB Device: SHANG CHEN HID
USB Device: Hub
USB Device: Hub
Thunderbolt Bus: Mac mini, Apple Inc., 23.4

Electron-builder conf:

electronBuilder: {
      builderOptions: {
        afterSign: 'notarize.js',
        productName: 'AppName',
        appId: 'com.appname.AppName',
        publish: {
          provider: 'github',
          repo: 'appname-releases',
          owner: 'AppName',
          vPrefixedTagName: true,
          host: 'github.com',
          protocol: 'https',
          private: false,
          releaseType: 'release',
          publishAutoUpdate: true
        },
        dmg: {
          sign: false,
          contents: [
            {
              x: 410,
              y: 150,
              type: 'link',
              path: '/Applications'
            },
            {
              x: 130,
              y: 150,
              type: 'file'
            }
          ]
        },
        mac: {
          hardenedRuntime: true,
          gatekeeperAssess: false,
          entitlements: 'entitlements.mac.plist',
          entitlementsInherit: 'entitlements.mac.plist',
          category: 'public.app-category.business',
          icon: 'src/assets/icons/icon.icns',
          target: [
            {
              target: 'mas'
            },
            {
              target: 'mas-dev'
            },
            {
              target: 'dmg'
            },
            {
              target: 'zip'
            }
          ]
        }
      }
    }

Entitlements:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.application-identifier</key>
    <string>xxx.com.appname.AppName</string>
    <key>com.apple.developer.team-identifier</key>
    <string>xxx</string>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <array>
      <string>xxx.com.appname.AppName</string>
    </array>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.inherit</key>
    <true/>
  </dict>
</plist>

Using macOS Mojave

Notice: The app has already been available and signed for almost over a year, is perhaps notarizing only needed for new apps?

I did set the build config back to 'sign: true' and disabled notarizing and everything works just like before. I haven't tried to install on a fresh mac though, but at least updating the app did work where it was previous installed.

[Kilian]

@steffanhalv You can't build a dmg and a mac app store app at the same time, they need different signing identities.

[steffanhalv]

@Kilian well, I could do that before. It used to create a .pkg file for mas and .dmg for mac when specifying multiple targets and the sign keys was fetched automatically from keychain for each build.

Perhaps it is the entitlements which is wrong? I also tried to comment out mas and create a build, but I got the same error :-/

[Kilian]

The mac app store also needs the sandbox entitlement and I don't think that works in the DMG?

[steffanhalv]

@Kilian You are correct, it was the entitlements. I leaved the entitlements as in the guide and created another one for mas, then it worked perfectly :)

Entitlements for .dmg was changed to this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
  </dict>
</plist>

[brunolemos]

Dunno if true or not but it seems there are more changes coming to dmg and notarization:

Another fun 10.15 nanny feature. You can no longer open DMGs if they aren’t notarized, even if the app within it is.
https://twitter.com/tapbot_paul/status/1153805577312591878?s=21

[pashvin]

Now I am able to notarize DMG and app both and works fine but ZIP has corrupted app. Is it because ZIP is created before it finish app notarization? Is there any workaround for that?

[DenisTsapelnikov]

hI,
Does someone have an open-source project with working notarization that I can use to find my problem?

[will-stone]

@DenisTsapelnikov I managed to get notarization working on mine: https://github.com/will-stone/browserosaurus/blob/master/scripts/notarize.ts The README shows the order in which I run scripts to publish. The project uses v6 of Electron Forge.

[DenisTsapelnikov]

@will-stone Can't get it to work either. Wanna ask the same question again with the usage of electron-builder instead of Electron Forge.

[mortalcompiler]

Hi I followed https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/ and got it to work using bitrise. Great stuff!

I have a question in the example afterSign script; the notarizing func is assigned to exports.default? Is this correct instead of exports default

exports.default = async function notarizing(context) {

[fabiospampinato]

I've published my webpack and electron-builder configuration here, which takes care of notarization as well. It will need some adaptations but it might be useful to have for somebody here.

[Kilian]

@mortalcompiler I don't get your question? You need to make your notarizing function the default export, yes.

[mortalcompiler]

Thanks for the reply, Let me expand, my question was around my confusion about the period(.) between exports and default.

exports.default = async function notarizing(context) {

exports.default (i.e. a CommonJS style module) will return a object with a function called 'default'.
So to use it would be something like this:

const notarize = require('./scripts/notarize.js');
notarize.default(context);

This is different from the ES module style:
export default function notarizing(context) { ... }
then importing like

import notarizing from './scipts/notarize.js';
notarizing(context);

[bobmoff]

I just want to say thanks to everyone in this thread putting in their time into fixing this, so that people like me can just follow instructions and get stuff working.

Amazing 🧡

[DominikLevitsky]

So we were trying to notarize our app. Using Electron 6.1.2 and also Electron 5.0.11. And electron-builder 22.1.0. With "hardenedRuntime": true, building a .dmg. On Catalina.

Both versions, packaging, signing and notarization works. But then, when launching the app after install, nothing works. Everything crashes with EXC_BAD_ACCESS (Code Signature Invalid). We tried everything and nothing worked. We were at despair.

But then suddenly, we have tried "hardenedRuntime": false, with notarization, which should not work at all. But guess what, it worked! We managed to launch the app and install it, and it even works on other computers, no warnings, everything smooth.

Maybe this will be helpful for someone struggling. But I am actually wondering: can someone explain how it is actually possible and what happened there?

[shahan312]

@DominikLevitsky Apple is currently allowing notarization with hardened runtime turned off until January 2020. See https://developer.apple.com/news/?id=09032019a

[DominikLevitsky]

@shahan312 Okay, this explains a part of the mystery. But why is it not working with hardenedRuntime turned on?

[semireg]

@DominikLevitsky, is it sandboxed, too? If so, HR and Sandbox seem to be mutually exclusive at the moment. See also https://github.com/electron-userland/electron-builder/issues/4040

[DominikLevitsky]

@semireg Not sandboxed. We are building for our own distribution, not for MAS.

[BeardedUnicorn]

Both versions, packaging, signing and notarization works. But then, when launching the app after install, nothing works. Everything crashes with EXC_BAD_ACCESS (Code Signature Invalid). We tried everything and nothing worked. We were at despair.

@DominikLevitsky That sounds like you are missing an entitlement.

[thomasdarde]

@pashvin did you find a fix to the corrupt .zip when notarizing an electron macos app ? We hit the same one and no idea of how to fix this

[thomasdarde]

I reference issue #4299 (explaining the .zip issue) here because I couldn't find it and lost a lot of time , so maybe it will help

[BeardedUnicorn]

This is long, but I'm hoping this might help others identify what is going on in their app. I've been dealing with Gatekeeper not accepting my notarized apps. (I highly recommend others download their notarized app from the internet to see how Gatekeeper treats the app when it's in quarantine.) On Catalina I would get '"App" cannot be opened because the developer cannot be verified.'

My setup:
The app is Angular with Electron, I use child process (exec/spawn) which calls a few binaries that are included with the application. I have electron-builder signing the application, the dmg is not signed and electron-notarize is doing the notarization. I followed the provided guide by @Kilian (thanks for that by the way, it was great to get up to speed quickly.) and was able to generate builds that are successfully notarized and launch without issues. (As soon as they were downloaded from the internet, I was then facing the Gatekeeper issues.)

Then I ran into "cannot be opened because the developer cannot be verified. macOS cannot verify that this app is free of malware." This was highly confusing because the app is signed and the notarization ticket was stapled to the app. I was using hardened runtime, and wasn't receiving any 'EXC_BAD_ACCESS' errors, so I knew this issue wasn't related to entitlements. I reviewed the Contents/_CodeSignature/CodeResources file bundled with the app and saw all of my files/dependencies listed. I ran spctl access -vvv MyApp.app and would get:

/Applications/MyApp.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: My Company. (L********)

I checked the signature on the application with codesign -vvv --deep --strict /Applications/MyApp.app/Contents/MacOS/MyApp and would get:

/Applications/MyApp.app/Contents/MacOS/MyApp: valid on disk
/Applications/MyApp.app/Contents/MacOS/MyApp: satisfies its Designated Requirement
--prepared:/Applications/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
--validated:/Applications/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
(There were many more prepared/validated, but no errors reported.)

I made some speculative changes which broke the bundling of dependencies and the app launched without Gatekeeper complaining. Immediately that brought the dependencies to light as the culprit. I checked the app to see if the dependencies were signed:

spctl --assess -vv /Applications/MyApp.app/Contents/Resources/app.asar.unpacked/libs/myPoorBinary
/Applications/MyApp.app/Contents/Resources/app.asar.unpacked/libs/myPoorBinary: rejected (the code is valid but does not seem to be an app)
origin=Developer ID Application: My Company (L**********)

Then I checked the binaries/dylibs themselves (before they are bundled by electron-builder) and they were not signed...

spctl --assess -vv dependencies/mac/myPoorBinary
dependencies/mac/myPoorBinary: rejected
source=no usable signature

This might seem right, electron-builder is signing the output files, so it should be right, right? This was THE issue. I'm not sure exactly why it's an issue, I have a few suspicions, but I haven't dug into them deeper yet.

After they were signed, Gatekeeper was no longer a issue with my builds!

[budowski]

@thomasdarde - the solution is to either:
A. Manually create the zip file out of the notarized .app file, as explained here.
B. Program the process as explained above in the link - just need to put it in a afterAllArtifactBuild script (under the build configuration for electron-builder) - this hook will be called after the .app file was generated, then you can compress it and create the YML file.

[thomasdarde]

Thanks @budowski , in the end I found a solution. I did try what you explain but it did not fix the issue for me. What did was to comment the line as explained here : https://github.com/electron-userland/electron-builder/issues/4299#issuecomment-541249788

And it's a good solution because I did not have to modify anything else.

[damianobarbati]

@develar any chance to have the PR fixing this released soon? 🙏

[albemala]

I confirm I've been able to notarize my Electron app by following this great article https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/ by @Kilian (thanks @Kilian !)

My setup:

• electron: 4.2.x
• electron-builder: 20.44.4
• electron-notarize: 0.2.1

[hugozap]

The recommended guide suggests not signing/notarizing the dmg but that's not what apple recommends ( sign/notarize the top container).
Looks like things can break if dmg is not notarized but from what I've read in the thread there's still not a quick way to do it with electron-builder. Am I wrong?

update:

I could successfully notarize the dmg (I'm also notarizing the app in a separate step) by adding a hook after all artifacts were built and calling a modified version of electron-notarize (one that does not zip the dmg file before sending it to apple servers).

The process changes the dmg file so blockmap and update files have to be updated, however it's possible to notarize and not stapling leaving the dmg file intact (this still works but users without connection will see apple warnings)

The modified electron-notarize in case someone else needs it.
https://github.com/hugozap/electron-notarize-dmg

[pliablepixels]

Does anyone know how to trigger afterSign just for mac? I have a multi platform build

Trying to put it inside the mac block results in an error

 "mac": {
      "category": "productivity",
      "target": "dmg",
      "icon": "icon.png",
      "entitlements": "build/entitlements.mac.plist",
      "entitlementsInherit": "build/entitlements.mac.plist",
      "hardenedRuntime": true,
      "gatekeeperAssess": false,
      "afterSign": "electron_js/notarize.js"
    },

Error:

  - configuration.mac has an unknown property 'afterSign'. These properties are valid: 
object { appId?, artifactName?, asar?, asarUnpack?, binaries?, bundleShortVersion?, bundleVersion?, category?, compression?, cscInstallerKeyPassword?, cscInstallerLink?, cscKeyPassword?, cscLink?, darkModeSupport?, detectUpdateChannel?, electronLanguages?, electronUpdaterCompatibility?, entitlements?, entitlementsInherit?, extendInfo?, extraDistFiles?, extraFiles?, extraResources?, fileAssociations?, files?, forceCodeSigning?, gatekeeperAssess?, generateUpdatesFilesForAllChannels?, hardenedRuntime?, helperBundleId?, helperEHBundleId?, helperGPUBundleId?, helperNPBundleId?, helperPluginBundleId?, helperRendererBundleId?, icon?, identity?, minimumSystemVersion?, protocols?, provisioningProfile?, publish?, releaseInfo?, requirements?, target?, type? }

I am running 22.4.0 of electron-builder and as per the docs, I can add common configuration items inside mac.

[jwheare]

You can bail out of the script if it’s not being run for Mac (darwin) artifacts. See https://github.com/irccloud/irccloud-desktop/blob/master/scripts/afterSign.js#L7

[pliablepixels]

Thanks. That is how I’ve set it up for now. Would have preferred a cleaner way but good for now.

[XRenSiu]

Does anyone know how to trigger afterSign just for mac? I have a multi platform build

Trying to put it inside the mac block results in an error

 "mac": {
      "category": "productivity",
      "target": "dmg",
      "icon": "icon.png",
      "entitlements": "build/entitlements.mac.plist",
      "entitlementsInherit": "build/entitlements.mac.plist",
      "hardenedRuntime": true,
      "gatekeeperAssess": false,
      "afterSign": "electron_js/notarize.js"
    },

Error:

  - configuration.mac has an unknown property 'afterSign'. These properties are valid: 
object { appId?, artifactName?, asar?, asarUnpack?, binaries?, bundleShortVersion?, bundleVersion?, category?, compression?, cscInstallerKeyPassword?, cscInstallerLink?, cscKeyPassword?, cscLink?, darkModeSupport?, detectUpdateChannel?, electronLanguages?, electronUpdaterCompatibility?, entitlements?, entitlementsInherit?, extendInfo?, extraDistFiles?, extraFiles?, extraResources?, fileAssociations?, files?, forceCodeSigning?, gatekeeperAssess?, generateUpdatesFilesForAllChannels?, hardenedRuntime?, helperBundleId?, helperEHBundleId?, helperGPUBundleId?, helperNPBundleId?, helperPluginBundleId?, helperRendererBundleId?, icon?, identity?, minimumSystemVersion?, protocols?, provisioningProfile?, publish?, releaseInfo?, requirements?, target?, type? }

I am running 22.4.0 of electron-builder and as per the docs, I can add common configuration items inside mac.

{
"appId":"xxxx",
"afterSign":"electron_js/notarize.js",
"mac":{}
}

[b-zurg]

The recommended guide suggests not signing/notarizing the dmg but that's not what apple recommends ( sign/notarize the top container).
Looks like things can break if dmg is not notarized but from what I've read in the thread there's still not a quick way to do it with electron-builder. Am I wrong?

update:

I could successfully notarize the dmg (I'm also notarizing the app in a separate step) by adding a hook after all artifacts were built and calling a modified version of electron-notarize (one that does not zip the dmg file before sending it to apple servers).

The process changes the dmg file so blockmap and update files have to be updated, however it's possible to notarize and not stapling leaving the dmg file intact (this still works but users without connection will see apple warnings)

The modified electron-notarize in case someone else needs it.
https://github.com/hugozap/electron-notarize-dmg

Have you successfully updated the blockmap? I'm not sure how to do that part.

[hugozap]

The recommended guide suggests not signing/notarizing the dmg but that's not what apple recommends ( sign/notarize the top container).
Looks like things can break if dmg is not notarized but from what I've read in the thread there's still not a quick way to do it with electron-builder. Am I wrong?
update:
I could successfully notarize the dmg (I'm also notarizing the app in a separate step) by adding a hook after all artifacts were built and calling a modified version of electron-notarize (one that does not zip the dmg file before sending it to apple servers).
The process changes the dmg file so blockmap and update files have to be updated, however it's possible to notarize and not stapling leaving the dmg file intact (this still works but users without connection will see apple warnings)
The modified electron-notarize in case someone else needs it.
https://github.com/hugozap/electron-notarize-dmg

Have you successfully updated the blockmap? I'm not sure how to do that part.

I'm only notarizing the app and dmg, not the blockmap. Updates are working fine.

[psukhanov]

The recommended guide suggests not signing/notarizing the dmg but that's not what apple recommends ( sign/notarize the top container).
Looks like things can break if dmg is not notarized but from what I've read in the thread there's still not a quick way to do it with electron-builder. Am I wrong?

update:

I could successfully notarize the dmg (I'm also notarizing the app in a separate step) by adding a hook after all artifacts were built and calling a modified version of electron-notarize (one that does not zip the dmg file before sending it to apple servers).

The process changes the dmg file so blockmap and update files have to be updated, however it's possible to notarize and not stapling leaving the dmg file intact (this still works but users without connection will see apple warnings)

The modified electron-notarize in case someone else needs it.
https://github.com/hugozap/electron-notarize-dmg

Have you tested this on macOS 10.14.5? I'm still running into the "Apple cannot check it for malicious software" message when trying to open a signed, notarized .dmg on that os version.

and
spctl --assess --type open --context context:primary-signature --verbose myapp.dmg
rejects with source=Unnotarized Developer ID

I'm tempted to go with Kilian's suggestion of not signing/notarizing the .dmg, but also worried this will break in future os versions :'(

[hugozap]

The recommended guide suggests not signing/notarizing the dmg but that's not what apple recommends ( sign/notarize the top container).
Looks like things can break if dmg is not notarized but from what I've read in the thread there's still not a quick way to do it with electron-builder. Am I wrong?
update:
I could successfully notarize the dmg (I'm also notarizing the app in a separate step) by adding a hook after all artifacts were built and calling a modified version of electron-notarize (one that does not zip the dmg file before sending it to apple servers).
The process changes the dmg file so blockmap and update files have to be updated, however it's possible to notarize and not stapling leaving the dmg file intact (this still works but users without connection will see apple warnings)
The modified electron-notarize in case someone else needs it.
https://github.com/hugozap/electron-notarize-dmg

Have you tested this on macOS 10.14.5? I'm still running into the "Apple cannot check it for malicious software" message when trying to open a signed, notarized .dmg on that os version.

and
spctl --assess --type open --context context:primary-signature --verbose myapp.dmg
rejects with source=Unnotarized Developer ID

I'm tempted to go with Kilian's suggestion of not signing/notarizing the .dmg, but also worried this will break in future os versions :'(

It worked for me on Mojave and it's working on Catalina. I'm using this (Note that for the dmg I'm not stapling the file, and using https://github.com/hugozap/electron-notarize-dmg)

This runs in the afterAllArtifactBuildHook

   return await notarize({
    appBundleId: config.build.appId,
    dmgPath: dmgPath,
    appleId: process.env.APPLEID,
    appleIdPassword: process.env.APPLEIDPASS,
    staple: false
  });

( Note: The dmg was created with an already notarized .app bundle - The .app bundle was notarized with the default electron-notarize package )

[psukhanov]

@hugozap gotcha, thanks! It looks like the critical piece for me is to not .zip the .dmg, as electron-notarize does by default (and as you show in your fork). 👍🤩

I assume the reason for that is because Apple's notary service then assumes that the .zip is the top-level package you will distribute in (in which case you should still be able to distribute the .zip without issue?) IN any case, thanks for the help!

[michaelpeterlee]

@Kilian blog post works for our project. We are now missing the app icon, however.

[alex-paterson]

Since adding notarization, my MAS app is immediately exiting with no error message on MacOS versions older than Catalina. Detail here https://github.com/electron/electron/issues/24423

[tudiantuan]

I confirm I've been able to notarize my Electron app by following this great article https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/ by @Kilian (thanks @Kilian !)

My setup:

• electron: 4.2.x
• electron-builder: 20.44.4
• electron-notarize: 0.2.1

Can you show file package.json?

[stakauskas]

Anyone facing issues on 10.15.7? I have app signed / notarized which works on 10.13.6 and 10.15.6, but on 10.15.7 it gives the message of:

"app" can't be opened because Apple cannot check it for malicious software.

[johnnysparav]

I have managed to notarize, sign and build .dmg by using electron-builder by following this guide:
https://david.dev/how-to-notarize-your-electron-app/

[codemanki]

@stakauskas i experience the same problem now. Did you manage to resolve this issue?

[thomasdarde]

We have an electron app containing other binaries and working from 10.3 to 11.0 (big sur).
It was a true pain in .. but it now works fine.

An important step was to use https://gist.github.com/harshitsilly/a1bd5a405f93966aad20358ae6c4cec5
to create the zip , the one created by electron-notarize was not valid.

Also copying the zip via scp to another computer was maybe an issue (I'm not sure of this), but passing via an http hosting was fine.

Last: the binary contained in our app had to be signed via command line , not in xcode. We use electron-notarize v 1.0.0, good luck

[stakauskas]

@stakauskas i experience the same problem now. Did you manage to resolve this issue?

Unfortunately - no. Still looking for a solution. Will check what @thomasdarde suggested.

[maitham]

Notarization seems to fail for me due to extra python .so files . Any ideas as to why, I assume they're not being picked up by electron builder. We've binarised our python files using Pyinstaller and included them in the Resources/main

  "build": {
    "asar": true,
    "afterSign": "scripts/notarize.js",
    "appId": "com.plato.app",
    "productName": "Plato",
    "directories": {  
      "buildResources": "resources"  
    },
    "mac": {
      "hardenedRuntime": true,
      "target": "dmg",
      "icon": "assets/app-icon.icns",
      "entitlements": "./build/entitlements.mac.plist",
      "entitlementsInherit": "build/entitlements.mac.plist"
    },
    "dmg": {
      "sign": false
    },
    "files": [
      "!models",
      "!main",
      "!bin",
      "!.env"
    ],
    "extraFiles": [
      {
        "from": "bin",
        "to": "Resources/bin"
      },
      {
        "from": "assets",
        "to": "Resources/assets"
      },
      {
        "from": "./main",
        "to": "Resources/main"
      },
      {
        "from": "./models",
        "to": "Resources/models"
      }
    ]
  }

[thomasdarde]

@maitham did you try to sign manually the .so files before notarizing the whole folder ?

codesign -s "Developer ID Application: XXXXX" --options=runtime --force --timestamp filepath