Electron-osx-sign: after sign the app,app crash

[tw234tw]

I used electron-packager to build the app
electron-packager . "test" --platform=mas --arch=x64 --overwrite --asar --app-bundle-id="xx.xxxxxx.xx" --app-version="1.4.0" --build-version="201730801"

and use osx-sign to sign it,

electron-osx-sign /Users/test-mas-x64/test.app --entitlements='/Users/test/parent.plist' --entitlements-inherit='/Users/test/child.plist' --platform=mas
and app signed successful,

but when I open it,it crash .

---

---

`Process: test [76424]
Path: /Users/USER/Downloads/*/test.app/Contents/MacOS/test
Identifier: xx.xxxxx.xx
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: test [76424]
User ID: 502

Date/Time: 2017-03-29 10:35:12.166 +0800
OS Version: Mac OS X 10.12.1 (16B2657)
Report Version: 12
Anonymous UUID: 92100232-AE6E-6007-A348-F50E82901732

Sleep/Wake UUID: 9E03B3CD-0D25-4753-8E38-6166BB507767

Time Awake Since Boot: 510000 seconds
Time Since Wake: 1800 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):
-->
mapped file 000000010e01e000-000000010e01f000 [ 4K] r-x/rwx SM=COW p

Thread 0 Crashed:
0 dyld 0x0000000116e5f000 _dyld_start + 0
1 ??? 0x000000010e01e000 0 + 4529971200

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

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

Binary Images:
0x116e5e000 - 0x116e9b287 dyld (421.2) /usr/lib/dyld

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: 15862703
thread_create: 0
thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=336K resident=0K(0%) swapped_out_or_unallocated=336K(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 2
Stack 8192K 2
VM_ALLOCATE 4K 2
__DATA 220K 3
__LINKEDIT 88K 2
__TEXT 248K 2
mapped file 20K 4
shared memory 8K 3
=========== ======= =======
TOTAL 64.6M 12

Model: MacBookAir6,2, BootROM MBA61.0099.B22, 2 processors, Intel Core i5, 1.4 GHz, 4 GB, SMC 2.13f15
Graphics: Intel HD Graphics 5000, Intel HD Graphics 5000, Built-In
Memory Module: BANK 0/DIMM0, 2 GB, DDR3, 1600 MHz, 0x80CE, 0x4B3445384533303445452D45474345000000
Memory Module: BANK 1/DIMM0, 2 GB, DDR3, 1600 MHz, 0x80CE, 0x4B3445384533303445452D45474345000000
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x117), Broadcom BCM43xx 1.0 (7.21.171.47.1a8)
Bluetooth: Version 5.0.1f7, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM0128F, 121.33 GB
USB Device: USB 3.0 Bus
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Rapoo 2.4G Wireless Device
Thunderbolt Bus: MacBook Air, Apple Inc., 23.6
`

---

---

[sethlu]

Hi @tw234tw, thanks for filing the issue! Are you trying to codesign your app bundle for distribution on the Mac App Store or just for local testing?

[tw234tw]

thank you @sethlu, I have codesign the app bundle for distribution on the Mac App Store,
it uesd to be a nw app,and now i want to rewrite it with electron(they use the same bundle).

[sethlu]

@tw234tw The app is expected to crash after signed for distribution on the Mac App Store. Due to this issue, to test the app before submitting it to iTC, I would suggest using the following template for signing: (A provisioning profile is used so that the local machine can run the app locally.)

electron-osx-sign <path-to-app> --platform=mas --type=development --entitlements="parent.plist" --provisioning-profile="development.provisioningprofile"

However, if you are sure about the effect after App Sandbox, the following template should work:

electron-osx-sign <path-to-app> --platform=mas --type=distribution --entitlements="parent.plist" [--provisioning-profile="distribution.provisioningprofile"]

I am unsure if the provisioning profile is totally optional for this case but I would recommend having one just in case. It will be removed by Apple when the app is ready for publishing.

---

Q: When I run my Mac app, it crashes immediately, and the crash log says Exception Type: EXC_CRASH (Code Signature Invalid). What is going on here?
https://developer.apple.com/library/content/qa/qa1884/_index.html

---

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

[quadrophobiac]

Not sure if it's correct for me to hijack this but also didn't want to file a new issue so close to my own.
I'm trying to sign an app for distribution outside the Mac App Store and have encountered the same error. Given that the crash is expected for MAS I was wondering if crashes for non mac app store distribution is also to be expected @sethlu .

These are the steps I am following:

• electron-packager . "App" --platform=darwin --arch=x64 --electron-version=1.4.13 --app-bundle-id="com.org.app" --app-version="0.5.0" --build-version="0.5.2" --ignore=docs --ignore=packages --icon=resources/icon.icns
• Can open app without crash
• app is unsigned
• run electron-osx-sign App/App.app --entitlements="packages/parent.plist" --entitlements-inherit="packages/child.plist"
• opening app triggers crash, with identical crash log as noted in the initial issue

I have configured the parent entitlements per the MAS instructions here - is that where I'm going wrong? IE by supplying it with those MAS details am I causing the crash to occur?

I want to pass entitlements files to enable my application to be able to open a certain filetype by default - maybe I'm barking up the wrong tree in that approach. I thought this was the correct thing to do based on <key>CFBundleDocumentTypes</key> and <key>CFBundleTypeExtensions</key> being fields that are stipulated in entitlements.plist and the Info.plist that is generated for a pacakged app. Any guidance you can offer would be appreciated

[sethlu]

@quadrophobiac

The following command should work I think:

electron-osx-sign App/App.app --type=development --entitlements="packages/parent.plist" --entitlements-inherit="packages/child.plist"

The --type=development flag tells electron-osx-sign to choose the development signing identity and provisioning profile automatically. Try export DEBUG=electron-osx-sign* (with the asterisk) before running the command and debug log should then be printed while processing.

Also, have you created a provisioning profile for development and for distribution already?

---

Regarding the file association, I'm not sure about the correct set up for it for that I've not worked with it myself. However, here are a few discussions I've found that can be useful... Do you have any suggestions for this scenario @malept?

• https://github.com/electron-userland/electron-packager/issues/59
• https://coderwall.com/p/83djxa/registering-your-app-to-be-able-to-open-images-from-other-apps
• https://github.com/webtorrent/webtorrent-desktop/issues/83#issuecomment-198814019 , and this commit https://github.com/webtorrent/webtorrent-desktop/pull/164/files#diff-9109eccc4c03527f26f8ead0327367e8R175

[malept]

I don't have any suggestions apart from what I said in the linked Packager issue.

[quadrophobiac]

Hey @sethlu, apologies for delay.

So I tried the command you supplied. I'm still encountering the same problem - once electron-osx-sign completes I cannot open the app without it crashing. Same crash report as before including this as the exception

Exception Type:        EXC_CRASH (Code Signature Invalid)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY
Termination Reason:    Namespace CODESIGNING, Code 0x1

The command picked up the correct certificate just like you said. Using ruby app checker and commands like spctl -a -v and codesign -v --strict --deep --verbose=2 show that there are no problems with the signature

I don't have a provisioning profile for dev or distribution - I'm going to look into that to see if that's the missing piece of the puzzle. Guides I read elsewhere told me that the provisioning profile was not required for distribution outside of the Mac App store - is that consistent with your experience?

Thanks also for the links on file association - I'm about to dive into them

[sethlu]

@quadrophobiac sorry this reply comes a little bit late.

Exception Type:        EXC_CRASH (Code Signature Invalid)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY
Termination Reason:    Namespace CODESIGNING, Code 0x1

On the error you received, I believe it is caused by not having a provisioning profile with the app bundle in development. Here's a little chart to explain:

| Build | Development | Distribution |
| ----------- | ----------- | ----------- |
| Inside the Mac App Store | Signed with the development certificate. Embed a provisioning profile for local testing, or the app will fail to launch (if sandbox enabled) | Signed with the 3rd party app certificate. Guess it's fine to skip embedding a provisioning profile if the app doesn't require any Apple services... But good to have it there |
| Outside the Mac App Store | - (same as above, but alternatively I mean it's fine not to enable sandbox if you plan not to use app sandbox for production) | Signed with the developer ID certificate. Only required to embed a provisioning profile if your app uses Apple services |

This chart is consistent with the electron-osx-sign guide.

And here I think you may need to generate the provisioning profile for development and embed it in your app bundle for testing purposes. The signature may be perfectly fine but it's just the missing provisioning profile that raises the issue.

And to address your second question, I think it's fine not to have a provisioning profile in your production app (for distribution outside the Mac App Store) if you don't plan to use Apple Services.

---

Amend (7/9/2017):

Actually, I just realized it's not really worth code signing a darwin build with app sandbox... So without app sandbox enabled, everything should work just fine, with a lot less hassle compared to making it MAS-compatible.

[gerges-zz]

I don't believe this needs to be the case. I'm currently migrating from a manual signature process to electron-forge. We've previously been able to test our app in the sandbox, and even distribute test builds to customers, just by launching it after signing. These are builds that were submitted to the app store, passed review, and are available for sale now (many times over). All of the invoked commands are the same, except the sign of the app with the parent.plist. The issue that appears to prevent run after sign are the inclusion of the following entitlements into the parent.plist

entitlements['com.apple.developer.team-identifier'] = appInfo.ElectronTeamID
entitlements['com.apple.application-identifier'] = appIdentifier

These entitlements also aren't included on the official electron app submission guide:

https://electron.atom.io/docs/tutorial/mac-app-store-submission-guide/

[sethlu]

Hi @gerges, the inclusion of these entitlements keys follow the documentation from Apple: https://developer.apple.com/library/content/qa/qa1884/_index.html, and I believe the same keys will also appear with some app exported for submission to the Mac App Store right from Xcode. Not sure whether it's better to have an additional feature to opt out injecting these entries.

[gerges-zz]

I'd argue it's worth it. It's been two years since that article was posted and this still isn't a hard requirement from Apple. Honestly as a consumer of electorn-osx-sign I was a bit surprised my entitlements file was being modified in-place, since the docs mention defaults. You don't need to expose this so directly, even a repairEntitlements: true option/default?

[sethlu]

@gerges electron-osx-sign should create a temporary file that hosts the entitlements change. An option's already implemented to skip this automation process: --no-pre-auto-entitlements/opts['pre-auto-entitlements'] == false. However, it is then necessary to have the ElectronTeamID entry in Info.plist and the com.apple.security.application-groups entry in the entitlements file before running electron-osx-sign.

More about the option: https://github.com/electron-userland/electron-osx-sign/blob/17c7f0e491291eba9f71984a3ef8e657e64feffc/util-entitlements.js#L26-L102

[sethlu]

Closing this issue for now since it's been inactive for quite a while.

[sangeeth96]

@sethlu I'm facing this issue with an example app I'm trying to package (to identify root issues of a bigger application). I'm using electron-packager to create the mas app and signing with electron-osx-sign thereafter. I've followed the instructions, placed the dev provisioning profile at the root and used the following to sign:

npx electron-osx-sign \
        --type=development \
        --platform=mas \
        "$APP_PATH"

However, the app crashes when I try to start with the same error as OP. I've checked to see if the profile is embedded within the app and it seems to be the case:

$ l out/Flock-mas-x64/Flock.app/Contents

Permissions Size User Date Modified Name
drwxr-xr-x     - ss    2 Apr  6:34  _CodeSignature
.rw-r--r--  7.7k ss    2 Apr  6:33  embedded.provisionprofile
drwxr-xr-x     - ss    2 Apr  6:33  Frameworks
.rw-r--r--  1.9k ss    2 Apr  6:33  Info.plist
drwxr-xr-x     - ss   24 Mar 23:02  Library
drwxr-xr-x     - ss    2 Apr  6:34  MacOS
.rw-r--r--     8 ss   24 Mar 22:13  PkgInfo
drwxr-xr-x     - ss    2 Apr  6:33  Resources

Verifying with security also tells me this is the development provisioning profile. Any idea what could the problem?

[sethlu]

@sangeeth96 Can you run electron-osx-sign again with export DEBUG=electron-osx-sign* (with the asterisk) and share the logs?

[sangeeth96]

@sethlu I'll move this to a new issue since it changed a bit from OP's original error after changing the entitlements.

[sangeeth96]

@sethlu Could you check #223? Thanks in advance.