Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mas app crashing after signing #897

Closed
workswithweb opened this issue Nov 11, 2016 · 24 comments · May be fixed by qcif/data-curator#563
Closed

mas app crashing after signing #897

workswithweb opened this issue Nov 11, 2016 · 24 comments · May be fixed by qcif/data-curator#563

Comments

@workswithweb
Copy link

workswithweb commented Nov 11, 2016

  • 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

@develar
Copy link
Member

develar commented Nov 11, 2016

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

@workswithweb
Copy link
Author

workswithweb commented Nov 11, 2016

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

@workswithweb
Copy link
Author

workswithweb commented Nov 11, 2016

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

@workswithweb
Copy link
Author

I am having app crash issue from 7.24.1

@develar
Copy link
Member

develar commented Nov 11, 2016

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

@develar develar changed the title MAC apps crashing after signing with error Code Signature Invalid No error if no valid cert to sign mac app Nov 11, 2016
@workswithweb
Copy link
Author

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)

@workswithweb
Copy link
Author

workswithweb commented Nov 11, 2016

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

@develar develar changed the title No error if no valid cert to sign mac app MAC apps crashing after signing with error Code Signature Invalid Nov 11, 2016
@develar develar changed the title MAC apps crashing after signing with error Code Signature Invalid mas app crashing after signing Nov 11, 2016
@develar develar reopened this Nov 11, 2016
@workswithweb
Copy link
Author

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 )

@chunkiat82
Copy link

chunkiat82 commented Nov 12, 2016

I have having this issue too.

But I managed to sign the app manually without issues.

@develar
Copy link
Member

develar commented Nov 12, 2016

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 (+ electron/osx-sign#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.

@develar
Copy link
Member

develar commented Nov 12, 2016

Reproduced.

@develar
Copy link
Member

develar commented Nov 12, 2016

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

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

@sethlu
Copy link
Member

sethlu commented Nov 12, 2016

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

@develar
Copy link
Member

develar commented Nov 13, 2016

All changes after electron/osx-sign@0fd220e were reverted. Sorry for inconvenience. Our test suite will be improved to avoid such issues in the future.

@sethlu
Copy link
Member

sethlu commented Nov 13, 2016

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

@sethlu
Copy link
Member

sethlu commented Nov 13, 2016

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

@develar
Copy link
Member

develar commented Nov 14, 2016

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

@sethlu
Copy link
Member

sethlu commented Nov 14, 2016

@develar I'll soon update guides to sign with the latest standard electron/osx-sign#106.

@mcfedr
Copy link

mcfedr commented Dec 6, 2016

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.

@develar
Copy link
Member

develar commented Jan 6, 2017

electron/osx-sign#105 (comment)

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.

@develar
Copy link
Member

develar commented Jan 6, 2017

@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)

@pie6k
Copy link

pie6k commented Apr 27, 2019

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

@sethlu
Copy link
Member

sethlu commented Apr 28, 2019

@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/

@pauljonescodes
Copy link

One thing that was contributing to this for me was that a certain entitlement is inexplicably required and commonly cited as being a string when it's an array of strings.

electron/osx-sign#281 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants