Electron-builder: mas app crashing after signing

Created on 11 Nov 2016  ยท  23Comments  ยท  Source: electron-userland/electron-builder

  • pre release 8.2.0
  • mas
  • electron": "1.4.6"

I was able to sign mas apps successfully with electron-builder 7.14.2 and publish on mac store. however after updating to 7.24.1, I started getting errors "Error: Exit code: 3. Command failed: spctl --assess --type execute --verbose --ignore-cache " which was fixed with issue#890 in 8.2.0 branch.

I updated electron-builder to pre-release branch 8.2.0 and when I build my app with gatekeeper-assess set to false, app is generated successfully however app crashes when we try to open. (attached is error screenshot) .

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

If I generate app without specifying gatekeeper-assess flag, I get "Error: Exit code: 3. Command failed: spctl --assess" back mentioned in issue#890
screen shot 2016-11-11 at 5 10 20 am

bug mac

Most helpful comment

I am not expert here and trust @sethlu. Issue reopened โ€” docs will be added about it.

All 23 comments

Please attach full build log (better to set env DEBUG=electron-builder).

Attached is the log file with DEBUG=electron-builder and when gatekeeper-assess set to false
downloaded

Attached is the log file when gatekeeper-assess not set
log2.zip

I am having app crash issue from 7.24.1

I see that you not only build mas, but for mac as well. And no valid Developer ID Application: in the keychain.

Ok. Thanks for the feedback. Will try including "Developer ID Application" or just build MAC apps. (I was not having this issue before when building both apps together)

Still having same issue while generating only for mas.
Attached is the logs.
log3.zip
Should I open new Issue or use the same?

May be below information is helpful.

I narrowed down issue to "electron-osx-sign-tf". (with electron-builder v 7.24.1)
If I use electron-osx-sign-tf version 1.0.1, it works fine.
using electron-osx-sign-tf version 1.1.0 is having above issue (I haven't tried electron-osx-sign-tf releases in between. If you need, I can try with other versions of electron-osx-sign-tf )

I have having this issue too.

But I managed to sign the app manually without issues.

Please provide debug log โ€” set env DEBUG=electron-builder,electron-osx-sign*

@sethlu If you have time, could you please help? electron-builder uses latest version of electron-osx-sign (+ https://github.com/electron-userland/electron-osx-sign/pull/80)

As @workswithweb discovered, "I use electron-osx-sign-tf version 1.0.1, it works fine", probably your latest changes is the reason of issue.

Reproduced.

Nov 12 17:50:35 develar-home-imac com.apple.xpc.launchd1: Binary is improperly signed.

https://gist.github.com/develar/265039c3ba26b52b38792283c74c2719

@develar I've already review the changes; sorry for it taking this long.

And @chunkiat82 I've just posted a PR addressing the unexpected team identifier in entitlements file, on which I will test and merge later.

All changes after https://github.com/electron-userland/electron-osx-sign/commit/0fd220e756060ca220455b1beb0f226242506356 were reverted. Sorry for inconvenience. Our test suite will be improved to avoid such issues in the future.

@develar would you check if your npm module published electron-macos-sign is up to date with the latest electron-osx-sign? Quite a few changes have been introduced since @0.4.0-beta4.

I think @chunkiat82 may have utilized some previous version of the codesigning tool. Also, it is normal to have EXC_CRASH (Code Signature Invalid) exception as described in https://developer.apple.com/library/content/qa/qa1884/_index.html.

@develar @chunkiat82 I would recommend generating a provisioning profile (wildcard is fine) for development first and then test signing with it first with --type=development.

I am not expert here and trust @sethlu. Issue reopened โ€” docs will be added about it.

@develar I'll soon update guides to sign with the latest standard https://github.com/electron-userland/electron-osx-sign/issues/106.

I'm not sure this issue is fixed, I was unable to submit my app, had to use the callback afterPack to embed a provisionprofile into the app.

https://github.com/electron-userland/electron-osx-sign/pull/105#issuecomment-260211431

This means that, going forward, distribution builds of Mac apps cannot be run directly; they are for submitting to iTunes Connect for app review only.

@sethlu Could you please confirm that electron-builder behaviour is correct? We use latest version of electron-osx-sign without any extra and changed defaults. Exactly as if user will use electron-osx-sign directly. Maybe electron-builder should warn that mas build cannot be run directly and provide special target to test mas build locally?

update: I see, probably electron-builder should introduce new target: mas-dev (--type=development)

I'm also having this issue, anyone found some solution?

@pie6k Please note that app bundles codesigned via electron-osx-sign will not run if using 3rd Party Mac Developer Application... Here's a summary of what leads to this somewhat unexpected behavior:

  1. With App Sandbox, the main/renderer Electron processes will have trouble communicating to each other, resulting in frozen renderer (so after codesign the app would launch just fine, but frozen).
  2. We can add application group property to the entitlements file to allow interprocess communication & add ElectronTeamID to Info.plist and the app should behave correctly after codesigning. โœ…

๐ŸŽฏ The above procedure corresponds to the following code signing script

electron-osx-sign path/to.app --no-pre-auto-entitlements --entitlements=mas.entitlements
# include "--type=development" for development ๐Ÿ˜… 

The mas.entitlements should include the following (minimal)

<?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.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <array>
        <string>XXXXXXXXXX.app-bundle-id</string>
    </array>
    <key>com.apple.application-identifier</key>
    <string>XXXXXXXXXX.app-bundle-id</string>
</dict>
</plist>

The Info.plist should include ElectronTeamID as XXXXXXXXXX.

With this setup, the app should launch with either signing certificate for development or distribution.


Some additional information from: https://github.com/electron-userland/electron-osx-sign/blob/b6fcaa570cf306771b3af9a8394ccd7037a74b25/README.md

Since electron-osx-sign adds the entry com.apple.developer.team-identifier to a temporary copy of the specified entitlements file (with the default option --pre-auto-entitlements) distribution builds can no longer be run directly. To run the app codesigned for distribution locally after codesigning, you may manually add ElectronTeamID in your Info.plist and com.apple.security.application-groups in the entitlements file, and provide the flag --no-pre-auto-entitlements for electron-osx-sign to avoid this extra bit. Note that "certain features are only allowed across apps whose team-identifier value match" (Technical Note TN2415).


Here's what electron-osx-sign does a little differently: Since Electron supports macOS features like Handoff, _when app sandbox is enabled_, electron-osx-sign (default with --pre-auto-entitlements) will automatically inject com.apple.developer.team-identifier into the entitlements to enable these features... and this entry must be whitelisted by a provisioning profile.

Therefore, electron-osx-sign requires provisioning profiles whenever app sandbox is enabled (applicable to MAS development and distribution). They will be picked up automatically if placed in the current working directory.

๐Ÿค” _I think the this entitlements automation behavior will likely change in a next major release of electron-osx-sign so the presence of provisioning profile should be what adds in the whitelisted entitlement entries, instead of when app sandbox is enabled._


To answer the question, the part marked ๐ŸŽฏ should be a workable code signing setup.

Alternatively, you can generate the provisioning profiles for development & for distribution on the MAS, place them in the current working directory, and trust electron-osx-sign to embed profiles and make the correct entitlements updates. Then the following script should do...

electron-osx-sign path/to.app
# include "--type=development" for development ๐Ÿ˜… 

More info: https://mintkit.net/electron-userland/electron-osx-sign/guide/

Was this page helpful?
0 / 5 - 0 ratings