Electron: Electron broken on OS X in Apple Sandboxed apps (App Store)

The Electron version was 0.36.1 MAS build.
I've tested with the 0.36.0 OS X version; sadly the same occurred.
Thanks again.

On this issue, I've already tested with v0.35.x (mas builds). Though still giving the deny mach-lookup logs, the graphics issue doesn't seem to occur at all.
Also need to mention: For the mas builds (tested with v0.36.0-v.36.7 mas builds), before signing with sandbox entitlements the application works fine. The graphics issue only appears after code-signed.
The darwin builds are not affected, as they do not get signed with entitlements for sandboxing.

Same here. I'm reverting back to v0.35.x for now. Maybe we need to wait until the upgrade to Chrome 48 over at atom/libchromiumcontent#175 arrives.

I have the same issue, and I'm using the very latest MAS build (0.37.1). This latest build upgrades to Chromium 49 so I thought it might resolve this, but it doesn't.

Just tested some of the recent releases of Electron:

• Electron v0.36.x darwin builds all work very well.
• Electron v0.36.x mas builds work with some glitch in graphics after sandboxed (I assume with CSS transitions and animations, or for things related to GPU)?
• Electron v0.37.0 darwin/mas fails to start (fixed in v0.37.1).
• Electron v0.37.1 darwin build has some glitch like that in Electron v0.36.x mas builds (before and after code signed for distribution).
• Electron v0.37.1 mas build has some glitch like that in Electron v0.36.x mas builds; however, it fails to load after sandboxed?

(cont'd) when signing with only sandbox entitlements for Electron v0.37.1 mas build:

3/14/16 5:23:51.171 PM sandboxd[395]: ([3742]) test-0.37.1 Help(3742) deny mach-lookup org.chromium.Chromium.rohitfork.3741
3/14/16 5:23:51.311 PM sandboxd[395]: ([3743]) test-0.37.1 Help(3743) deny mach-lookup org.chromium.Chromium.rohitfork.3741
3/14/16 5:23:51.461 PM sandboxd[395]: ([3744]) test-0.37.1 Help(3744) deny mach-lookup org.chromium.Chromium.rohitfork.3741
3/14/16 5:23:51.719 PM Electron[3741]: __net_helper_get_connection_block_invoke_3 could not connect to networkd
3/14/16 5:23:51.719 PM Electron[3741]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start callback failed, dumping backtrace:
        [x86_64] libnetcore-583.20.10
    0   libsystem_network.dylib             0x00007fff96104ba5 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff9611de68 __nw_path_evaluator_start_helper_connection_block_invoke + 22
    2   libxpc.dylib                        0x00007fff8c19691f _xpc_connection_reply_callout + 26
    3   libxpc.dylib                        0x00007fff8c1968c0 _xpc_connection_call_reply + 36
    4   libdispatch.dylib                   0x00007fff9b90b33f _dispatch_client_callout + 8
    5   libdispatch.dylib                   0x00007fff9b90ff6f _dispatch_queue_drain + 754
    6   libdispatch.dylib                   0x00007fff9b91663b _dispatch_queue_invoke + 549
    7   libdispatch.dylib                   0x00007fff9b90ec87 _dispatch_root_queue_drain + 538
    8   libdispatch.dylib                   0x00007fff9b90ea34 _dispatch_worker_thread3 + 91
    9   libsystem_pthread.dylib             0x00007fff91b6768f _pthread_wqthread + 1129
    10  libsystem_pthread.dylib             0x00007fff91b65365 start_wqthread + 13
3/14/16 5:23:51.720 PM Electron[3741]: nw_path_evaluator_start_helper_connection net_helper_path_evaluation_start failed, dumping backtrace:
        [x86_64] libnetcore-583.20.10
    0   libsystem_network.dylib             0x00007fff96104ba5 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff9611a228 nw_path_evaluator_start_helper_connection + 196
    2   libdispatch.dylib                   0x00007fff9b916871 _dispatch_call_block_and_release + 12
    3   libdispatch.dylib                   0x00007fff9b90b33f _dispatch_client_callout + 8
    4   libdispatch.dylib                   0x00007fff9b90ff6f _dispatch_queue_drain + 754
    5   libdispatch.dylib                   0x00007fff9b91663b _dispatch_queue_invoke + 549
    6   libdispatch.dylib                   0x00007fff9b90ec87 _dispatch_root_queue_drain + 538
    7   libdispatch.dylib                   0x00007fff9b90ea34 _dispatch_worker_thread3 + 91
    8   libsystem_pthread.dylib             0x00007fff91b6768f _pthread_wqthread + 1129
    9   libsystem_pthread.dylib             0x00007fff91b65365 start_wqthread + 13
3/14/16 5:23:51.917 PM sandboxd[395]: ([3741]) Electron(3741) deny mach-lookup com.apple.network

I thought Electron may try to load up remote resources, so then added entitlements (still with sandbox) for network client:

3/14/16 5:27:58.223 PM sandboxd[395]: ([3795]) test-0.37.1 Help(3795) deny mach-lookup org.chromium.Chromium.rohitfork.3794
3/14/16 5:27:58.378 PM sandboxd[395]: ([3796]) test-0.37.1 Help(3796) deny mach-lookup org.chromium.Chromium.rohitfork.3794
3/14/16 5:27:58.523 PM sandboxd[395]: ([3797]) test-0.37.1 Help(3797) deny mach-lookup org.chromium.Chromium.rohitfork.3794

Interesting, the logs about networking disappeared. However, the app still doesn't load properly with something blank as attached.

Looks a bit different from https://github.com/atom/electron/issues/3771.

Same issue on 0.37.1.

Looks like the issue comes from the recent CEF builds:
http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=13469

FYI: prepared the two Electron-MAS binaries to reproduce the issue.
https://drive.google.com/folderview?id=0B8jpVsBA-4FrOTllTlZGOU5JeFU&usp=sharing

Electron_v0.35.6-mas.app can be launched while Electron_v0.37.2-mas.app does not work. The only difference between them is MAS version.

FYI2: FYI https://github.com/electron-userland/electron-osx-sign/wiki/2.-Electron-Compatibility

Just tested; the same from Electron v0.37.1 appears in v0.37.2.

Can confirm this for 0.37.2

Seems that the launching issue in v0.37.1's been fixed in v0.37.2. However, v0.37.2 mas seems failing when sandboxed; it freezes with the window showing up.

Using v0.37.2 with MAS sandbox, I can create new browser windows, but the app freezes after I call browserWindow.loadURL(someURL). There are no errors printed in the console.

v0.36.2 works perfect after signing, but after signing v0.37.2, the app keeps showing "Not responding" and no window showed up.

I got the same issue as @fuermosi777. The signed app (v0.37.2) kept not responding while it worked perfect with v0.35.4.

Related logs here: https://gist.github.com/luin/33074d4f340aba0cc000

Hi, I'm a product manager at JANDI, a business messaging platform from South Korea, which is being used by dozens of thousands active users everyday. We're trying to shift to Electron for our web app but this particular issue is a major road block for us for releasing to MAS. I really wish this issue can be solved in a near future so that we can add my product to the list of Electron-used services. Always appreciating the hard work of the crew. Thanks.

Just tested; the same from Electron v0.37.1 appears in v0.37.2.

Hey, just some updates with my testing with v0.37.3:

Before sandboxing/codesigning:

• darwin build works, with some slight graphics issues.
• mas build the same as above.

After sandboxing/codesigning:

• darwin build has some graphics issue drawing the elements when animating, as far as I've tested.
• mas build doesn't really load up the webpage, and freezes. It doesn't crash by itself, needs terminating.

I'm thinking about changing a title for this issue, as rohitfork and iosurfacemgr aren't the real factors causing these issues. :confused:

same problem, looking forward for fix

sad thing I need API introduced at 0.36.11 and can't just use old mas build.
any workaround ideas?

This is a super important bug for us at Slack, we'll probably have a look at this soon

For people interested in fixing this, here are some hints:

• The root cause is after sandboxing Chromium's IPC system starts to have troubles, in 0.36 GPU process is unable to start, and in 0.37 even renderer process is not able to run.
• This starts to happen from 0.36, which upgrades Chromium from 45 to 47.
• I believe this is because Chromium started to use XPC instead of raw mach messages for IPC.

Related issues in Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=382931
https://bugs.chromium.org/p/chromium/issues/detail?id=367863

A possible solution is to force using old system by setting is_yosemite_or_later_ to false in PreExecDelegate::PreExecDelegate:
https://code.google.com/p/chromium/codesearch#chromium/src/sandbox/mac/pre_exec_delegate.cc&sq=package:chromium&type=cs&l=37

But from the Chromium issue they switched to use XPC because from Yosemite the old implemented is not compatible with the OS and crash happens.

@zcbenz Part of the problem is that the XPC name is suffixed with a PID, so it's impossible to include in the entitlements. Can we just remove the suffix and instruct people to include the XPC name?

@paulcbetts I'm not sure, I didn't have time to take a deep look at it.

@zcbenz Lemme try to get set up with building custom libchromiumcontent and I'll have a go tomorrow

For people watching this issue, you can just follow the latest guide to get Electron sandboxed for Mac App Store, there is no need to wait for next release.

The key change is adding an entry to entitlements:

    <key>com.apple.security.temporary-exception.sbpl</key>
    <string>(allow mach-lookup (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))</string>

Hi @zcbenz, thanks for suggesting this solution! 👍 However, it is quite uncertain if it is mack-lookup that prevents Electron from behaving normally after codesign; from my tests just now with Electron v0.37.7 both darwin and mas, the graphics seem still a bit glitchy when the CSS transitions take place. May I ask if there be any thoughts on this? Many thanks, and again to this issue.
P.S.: I wonder if the temporary exception will pass mas review though. 😕 I don't really have a working version for submission to iTC.

FYI: I submitted an app (electron 0.37.3) with these changes and it got approved.

@herrmannplatz Thanks for the info! 👍
I'm just still wondering if there be any follow ups on the graphics... May I ask if the GPU-related issues are resolved as well? Thanks in advance.

@zcbenz Thanks for the workaround. I was able to run my app fine. However, I am still getting some errors in my console. Do you have any idea what are these console logs about? What are the consequences if I go with them? And how can I solve that?

4/27/16 10:30:00.325 PM taskgated[110]: no application identifier provided, can't use provisioning profiles [pid=4904] 
4/27/16 10:30:00.000 PM kernel[0]: Sandbox: SampleApp(4904) deny file-read-data / 
4/27/16 10:30:10.000 PM kernel[0]: Sandbox: SampleApp(4904) deny file-read-data /Users/hp011235/Library/Preferences/com.apple.symbolichotkeys.plist

@herrmannplatz I just received the following rejection:

my explanation for submission:

This application leverages Chromium to deliver our experience. Bundled within the app is Chromium, which uses the Mach port for its multi-process architecture. The string used is: (allow mach-lookup (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))

What did you do different to get accepted?

@zcbenz I was rejected by Apple for the temporary entitlement, any workarounds?

Sounds like typical app store arbitrary decision making. Ill be submitting my app today, fingers crossed...

@mcfedr good luck with your iTC submission!
(I'm still thinking if it's more compatible to fallback to v0.35.x because it very nicely works... 😕 I haven't recently got much time, but'll see if there be any nice fixes with Chromium.)

Hi, may we reopen this issue? I've just finished testing v1.1.3 and v1.2.0 with the signing specs at described https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md. Not sure why but the mas app freezes at launch after sandboxed?
Anyone experiencing the same issue or is it just me whom encountered this... Darwin build works though (well without sandbox).

@sethlu My app also started freezing when sandboxed after updating Electron from v1.1.0 to 1.2.0. The problem went away after I upgraded electron-packager to the latest version and I added com.apple.security.application-groups and ElectronTeamID keys as described in the updated MAS submission guide.

@jarek-foksa great! Thanks for your comment. I was keeping rebuilding with v1.1.3 and launching v1.2.0... Figured out why it didn't work earlier. 😸
Thanks to @zcbenz for introducing this mechanism; worked perfectly so far! Seems all err messages disappeared with app groups.

My 1.2.0 app also won't start anymore after I signed it according to the latest app store submission guide. It just briefly shows the icon and then closes again.

When I remove the last codesign line:
codesign -s "$APP_KEY" -f --entitlements "$PARENT_PLIST" "$APP_PATH"
The app opens again but with this error message: "Process is not in an inherited sandbox."

When I remove the second to last line:
codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$APP_PATH/Contents/MacOS/$APP"
The app works again, but then it's not fully signed anymore of course.

I have followed the instruction closely and I don't know what's wrong. Also when I install the app through the pkg file it won't run.

@Janneman84 if you are upgrading to 1.2 you need to update your entitlements, check the app store docs

Please be more specific, I believed the current guide is up to date:
https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md

Can you tell me what according to you is missing and where?

@Janneman84 Have you added ElectronTeamID to the Info.plist (as required by Electron version >= 1.1.1) yet? Otherwise you may have a check if com.apple.security.application-groups has been correctly set up as described in the doc in your entitlements file, which should be TEAM_ID.app.bundle.id. Let us know if everything's checked yet error persists.

I followed the instructions carefully, including adding the ElectronTeamID in the Info.plist and the bundle id in the other file. I've tried several times.

Is there any way to get some kind of log of the crash? All that happens now is that it opens and closes again, nothing else.

@Janneman84 would you give electron-osx-sign a try? I'm not very sure where the code signing got wrong. It may be done with the following script:

# May install the module with: npm install -g electron-osx-sign
export DEBUG=electron-osx-sign*
electron-osx-sign path/to/my.app

Worth noting that with export DEBUG=electron-osx-sign* you have view the full log during signing. Would you cross out some of your private info first and post them here?

We may just use the default entitlements to get the app running first after sandboxed I think if you don't have code at launch that accesses parts of the system which needs entitlement keys.

Okay I started with a clean unsigned app (that runs) and added the team id to the Info.plist. Then I tried electron-osx-sign. First I got "No identity found for signing".
Then I manually added the app key with --identity=1662E**, now it worked (no errors).
However the signed app file won't run anymore, same problem as before.

By the way I created the app using the latest gulp-electron, does that matter at all?

  electron-osx-sign Signing application... +0ms
  electron-osx-sign > application         myapp.app/ +2ms
  electron-osx-sign > platform            mas +2ms
  electron-osx-sign > entitlements        /usr/local/lib/node_modules/electron-osx-sign/default.mas.entitlements +0ms
  electron-osx-sign > child-entitlements  /usr/local/lib/node_modules/electron-osx-sign/default.mas.inherit.entitlements +0ms
  electron-osx-sign > additional-binaries  +1ms
  electron-osx-sign > identity            1662E**** +0ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework +90ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib +2s
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib +485ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework +633ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper EH.app/Contents/MacOS/Electron Helper EH +2s
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper EH.app +319ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper NP.app/Contents/MacOS/Electron Helper NP +273ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper NP.app +267ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper +394ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper.app +399ms
  electron-osx-sign Signing... myapp.app/Contents/MacOS/Electron +390ms
  electron-osx-sign Signing... myapp.app/ +600ms
  electron-osx-sign Verifying sign... +529ms
  electron-osx-sign Verifying entitlements... +166ms
Application signed: myapp.app/

@Janneman84 well, may you check either from your KeyChain Access app from Utilities or with $ security find-identity -v -p codesigning that you have 3rd Party Mac Developer Application: *?

I'm thinking if a different cert is used with signing.

I think I'm having the same issue as @Janneman84. I can build my app for "mas" and it runs fine. But when I sign it (no issues during signing), I get a bunch of sandbox related errors (see below). I have the 3rd Party Mac Developer Application certificate.

I was able to build and sign the "darwin" version of the app (required signing some additional components within the app bundle) and it ran fine, but got rejected from MAS for using QuickTime or QTKit APIs. Actually, looks like "darwin" build now has the same issue for me—maybe I updated some component like electron-packager and that caused the problem...

6/8/16 09:20:24.176 taskgated[472]: no application identifier provided, can't use provisioning profiles [pid=54551]
6/8/16 09:20:24.997 com.apple.xpc.launchd[1]: (com.apple.ReportCrash[54553]) Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash
6/8/16 09:20:25.869 MyElectronApp[54551]: __net_helper_get_connection_block_invoke_3 could not connect to networkd
6/8/16 09:20:25.869 MyElectronApp[54551]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start callback failed, dumping backtrace:
        [x86_64] libnetcore-583.50.1
    0   libsystem_network.dylib             0x00007fff92595de9 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff925b058f __nw_path_evaluator_start_helper_connection_block_invoke + 22
    2   libxpc.dylib                        0x00007fff8901a333 _xpc_connection_reply_callout + 26
    3   libxpc.dylib                        0x00007fff8901a2d4 _xpc_connection_call_reply + 36
    4   libdispatch.dylib                   0x00007fff8733740b _dispatch_client_callout + 8
    5   libdispatch.dylib                   0x00007fff8733c03b _dispatch_queue_drain + 754
    6   libdispatch.dylib                   0x00007fff87342707 _dispatch_queue_invoke + 549
    7   libdispatch.dylib                   0x00007fff8733ad53 _dispatch_root_queue_drain + 538
    8   libdispatch.dylib                   0x00007fff8733ab00 _dispatch_worker_thread3 + 91
    9   libsystem_pthread.dylib             0x00007fff86ab04de _pthread_wqthread + 1129
    10  libsystem_pthread.dylib             0x00007fff86aae341 start_wqthread + 13
6/8/16 09:20:25.870 MyElectronApp[54551]: nw_path_evaluator_start_helper_connection net_helper_path_evaluation_start failed, dumping backtrace:
        [x86_64] libnetcore-583.50.1
    0   libsystem_network.dylib             0x00007fff92595de9 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff925ac89f nw_path_evaluator_start_helper_connection + 196
    2   libdispatch.dylib                   0x00007fff8734293d _dispatch_call_block_and_release + 12
    3   libdispatch.dylib                   0x00007fff8733740b _dispatch_client_callout + 8
    4   libdispatch.dylib                   0x00007fff8733c03b _dispatch_queue_drain + 754
    5   libdispatch.dylib                   0x00007fff87342707 _dispatch_queue_invoke + 549
    6   libdispatch.dylib                   0x00007fff8733ad53 _dispatch_root_queue_drain + 538
    7   libdispatch.dylib                   0x00007fff8733ab00 _dispatch_worker_thread3 + 91
    8   libsystem_pthread.dylib             0x00007fff86ab04de _pthread_wqthread + 1129
    9   libsystem_pthread.dylib             0x00007fff86aae341 start_wqthread + 13
6/8/16 09:20:26.015 sandboxd[53153]: ([54552]) MyElectronApp Helper(54552) deny forbidden-sandbox-reinit
6/8/16 09:20:26.042 sandboxd[53153]: ([54554]) MyElectronApp Helper(54554) deny forbidden-sandbox-reinit
6/8/16 09:20:26.067 sandboxd[53153]: ([54555]) MyElectronApp Helper(54555) deny forbidden-sandbox-reinit
...

@Janneman84 @masonicboom Sorry but I'll have to investigate slightly more before knowing what exactly causes this issue, with reference to the err message from taskgated.
However, could you both try to create a test case with electron-quick-start and see if codesign passes with app successfully launching? Then we may exclude failing at code signing identities.

Also @Janneman84, I'm not sure if gulp-electron supports native mas build. Did you attempt to remove Squirrel.framework or anything from inside .app/Contents/Frameworks before signing?

May you display your commands with gulp-electron (excluding any sensitive info)?

I actually sneakily replaced the app in the cache folder with the mas version so gulp-electron would use that one when building. The app it creates does not have the Squirrel framework or other stuff in it that the mas version shouldn't have. All the required folders and files are there, and it runs fine before signing. I'll try a different packager tomorrow just to be sure.

I also found out that I was using a wrong certificate. I fixed that now, but the problem still persists, also when using electron-osx-sign.

A similar issue here https://github.com/electron-userland/electron-osx-sign/issues/59

I've just done some tests with packing different versions of Electron and realized that it may be the additional signing steps, which indeed resolved some issues, that caused the recent problem from code signing products. I think, there is nothing that probably went wrong during your signing processes @Janneman84 @masonicboom.

I've tried to remove the application group from the entitlements which of course lead to app hanging at startup (and this situation's why ElectronTeamID is introduced) but then the error log disappeared from Console. So probably the only reason for emission of no application identifier provided... is from this additional spec we made in the entitlements.

So far I haven't had too much thoughts about overcoming this but the application group approach is very welcome. I'll have you known where finding any info useful.

Hi I'm back with probably a partly-sure response which I'll start drafting tmrw.

What I have learnt from researching, in some nice sentences, is the following:

• Apple's started to disable local tests of apps sent off to MAS submission some time ago; however, local tests may be done with development provisions (meaning limited devices registered with your UUIDs I think). It's like turning to be an iOS where you needs to have your iPhones/iPads registered before testing out from the simulators.
• There are a few more entitlement keys to be added in order for the app to run, for both testing for development/production; however, once adding some required by MAS submission, your app will crash at start 😕 but that's fine to be submitted for review in a production release. (I'll figure out a better way to phrase this tmrw.)
• There is an embedded provisioning profile embedded.provisionprofile that needs placing within your sealed app Contents folder for MAS review. (And this partly caused app resisting launching when testing locally for a production version.)
• taskgated steps in when application group is set (from my observation) and it looks for provisioning profiles... Either from an embedded profile (like what iOS developers always work with) or an installed development profile (as in point 1).

I know some of the words above don't make too much sense. However, these should only apply to situation where we use application groups I think. With earlier versions of Electron (<1.1.1), there's no need to worry too much as nothing just being said's really necessary.

Some refs:

• https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppStoreDistributionTutorial/LaunchingYourApponDevices/LaunchingYourApponDevices.html
• https://developer.apple.com/library/mac/qa/qa1884/_index.html
• https://developer.apple.com/library/mac/qa/qa1778/_index.html
• https://developer.apple.com/library/ios/qa/qa1710/_index.html

Sorry but I've been loosing track of several other resources... The above are directly from Apple. Tbh, it'll be quite some fun working with MAS distribution from now.

@Janneman84 @masonicboom @jpittner Would you mind having a check on https://github.com/sethlu/electron-distribution-guide/blob/master/DevelopmentSignedApplication.md? I've drafted an updated/conceptual signing procedure that allows the app running with application groups enabled. I got my electron-quick-start app running with this and sandbox enabled.

However, please note that this document is only for testing on your machine with mas build. After a second document is drafted on submitting to review, hopefully by tomorrow, I'll get more info so your app could get running on Mac App Store. (Sorry for the word count... It's a bit wordy I apologize.)

@sethlu I'm really curious how you've managed to figure any of this stuff out! For what it's worth here's where I can get the app following your directions (from console logs). The app crashes, but at least the error messages make somewhat sense and go back to the days before the application group, rather than saying silly things like no encoders for avc1 found.

10-6-2016 6:47:20.069 PM taskgated-helper[78694]: validated embedded provisioning profile: file:///Users/jan/workspace/MyApp.app/Contents/embedded.provisionprofile
10-6-2016 6:47:20.069 PM taskgated-helper[78694]: Found 1 provisioning profiles
10-6-2016 6:47:20.069 PM taskgated-helper[78694]: allowing entitlement(s) for pid=78704 due to provisioning profile
10-6-2016 6:47:20.631 PM MyApp Helper[78706]: GVA info: preferred scaler idx 0
10-6-2016 6:47:20.662 PM sandboxd[3764]: ([78706]) MyApp Helper(78706) deny mach-lookup com.me.MyApp.rohitfork.78704
10-6-2016 6:47:20.782 PM sandboxd[3764]: ([78707]) MyApp Helper(78707) deny mach-lookup com.me.MyApp.rohitfork.78704
10-6-2016 6:47:21.463 PM MyApp[78704]: __net_helper_get_connection_block_invoke_3 could not connect to networkd
10-6-2016 6:47:21.464 PM MyApp[78704]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start

The parent entitlements are below. child entitlements are as usual with the inherit key and the sandbox key.

<?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>*******EKS.com.me.myApp</string>
    </array>
    <key>com.apple.security.files.user-selected.read-write</key>
    <true/>
    <key>com.apple.application-identifier</key>
    <string>*******EKS.com.me.myApp</string>
    <key>com.apple.developer.team-identifier</key>
    <string>*******EKS</string>
    <key>com.apple.security.temporary-exception.shared-preference.read-only</key>
    <array>
            <string>com.apple.symbolichotkeys</string>
      </array>
 </dict>
  </plist>

Signed with the script, with additional binary of the spellchecker.node signed.

Codesign --verify --deep gives

: valid on disk
: satisfies its Designated Requirement

This was signing with the Mac Developer identity (that has a different code rather than *EKS). Trying to sign the "3rd Party Mac Developer Application" results in the app crashing with the error - killed com.me.MyApp[pid 78772] because its use of the com.apple.developer.team-identifier entitlement is not allowed (error code -67050)

@jpittner we had a similar problem just the other day when a member of our team tried to build a signed version to try the sandbox.

The first problem was not having the proper certificates and private keys in the Keychain. The symptom of this was that the signing failed with an "identity not found"-error.

But after that the problem ended up being that the version of electron-osx-sign we used was not the most recent one (0.4.0-beta4), and before 0.4.0 it does not inject the team id into *.app/Contents/Info.plist which is needed after Electron 1.1.2. The end result was that it just froze with no errors except the sandboxd deny mach-lookup .rohitfork. in Console.app, like you mentioned above.

@jpittner Thanks for trying out! There were quite some trials and errors lol. Following are some of my thoughts upon your console messages received:

10-6-2016 6:47:20.069 PM taskgated-helper[78694]: validated embedded provisioning profile: file:///Users/jan/workspace/MyApp.app/Contents/embedded.provisionprofile
10-6-2016 6:47:20.069 PM taskgated-helper[78694]: Found 1 provisioning profiles
10-6-2016 6:47:20.069 PM taskgated-helper[78694]: allowing entitlement(s) for pid=78704 due to provisioning profile

The above I think represents that the settings with signings and provisioning profiles are set up correctly for development.

10-6-2016 6:47:20.631 PM MyApp Helper[78706]: GVA info: preferred scaler idx 0

This just occurs from Helper naturally. 😕

10-6-2016 6:47:20.662 PM sandboxd[3764]: ([78706]) MyApp Helper(78706) deny mach-lookup com.me.MyApp.rohitfork.78704
10-6-2016 6:47:20.782 PM sandboxd[3764]: ([78707]) MyApp Helper(78707) deny mach-lookup com.me.MyApp.rohitfork.78704

Would you have a check in your Info.plist and make sure that ElectronTeamID has been added, which follows *******EKS from what appeared to be from your provisioning profile:

<key>com.apple.developer.team-identifier</key>
<string>*******EKS</string>

Personally I think this error has been fixed with an earlier update from Electron where application group is used. So probably the only cause of it should be from either Info.plist or the entitlements file, which in your case should already be set up properly.

10-6-2016 6:47:21.463 PM MyApp[78704]: __net_helper_get_connection_block_invoke_3 could not connect to networkd
10-6-2016 6:47:21.464 PM MyApp[78704]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start

I'm not sure why Chromium starts complaining about the network connections (in case if you don't want access to remote servers). However, you may levitate this issue by adding an additional entitlements key: com.apple.security.network.client to allow connection to web server (or if there isn't one).

On your note upon singing with 3rd Party Mac Developer Application, the error should occur... This is said by Apple to be by design... I haven't had time to have this covered within my draft on the submission to MAS document. But yea, there isn't a possible way to test the real app which to be sent for review but using the Mac Developer, to abide by the Apple's modern updates.

Yet we sort of sneakily got around this by not setting application group!? I'm not yet sure if we may get around these excess steps which seem slightly unnecessary. However, in even a basic blank-screen app in Obj-C/Swift packaged from Xcode. The signing/test scheme follows in a same way. 😅 I don't really know what Apple's going for but the change slightly implies a paradox-like situation where test flights are to be available on Mac... lol.

Let me know how it goes.

@slaskis from my trials the identity not found may be caused by not specifying com.apple.application-identifier... However, with this entry added, the system may complain more by asking for provisioning profiles, which became the reason of my trying out those profiles with Electron.

Also, I'm not quite sure why errors about mach-lookups still persists 💭 if ElectronTeamID's set properly in Info.plist and com.apple.security.application-groups is properly set in the entitlements file. However, we haven't open any PRs with respect to the document mentioned earlier as the current workflow doesn't really match the one from Apple. Previously we haven't distinguished development or distribution because the app runs even after sandbox for MAS submission... Not it appears that it should not.

Ref: https://developer.apple.com/library/mac/qa/qa1884/_index.html

Distribution builds of apps that use those technologies may be submitted to iTunes Connect for review, but until then, aren’t allowed to run and are killed on launch. This is because distribution provisioning profiles do not contain a list of hardware UUIDs that restrict the app to a specific set of devices. This is similar to iOS where distribution builds have never been allowed to run on a device.
Recently, the com.apple.developer.team-identifier entitlement was added to all new Mac provisioning profiles. 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.
Instead, developers should adopt the Archive Build Workflow in QA1778: How to reproduce bugs reported against Mac App Store submissions for testing the builds that they plan to submit for the Mac App Store. On Xcode 6, select Export as a Mac Application. You won't see any chance to select your development signing identity, but Xcode will export the app from the archive as it was signed at build time. So the result will be the same.

Please mind that some of the words there doesn't really apply to our situation as we don't interfere with Xcode during this part. sigh

In case anyone's interested, I'm using the following script to do the current code signing procedure, just to have thing speeded up:

APP="MyApp.app"
TEAM_ID="XXXXXXXXXX" # Note this is the actual "team" id, not your personal one that appears to be on your Mac Developer signing identity
DEVELOPMENT_PROVISIONING="development.provisionprofile"
SIGNING_IDENTITY="Mac Developer"

# Copies the development provisioning to inside the app contents
cp "${DEVELOPMENT_PROVISIONING}" "${APP}/Contents/embedded.provisionprofile"
# Adds the ElectronTeamID into Info.plist
plutil -insert ElectronTeamID -string "${TEAM_ID}" "${APP}/Contents/Info.plist"
# Code signs the product... Note the --no-pre-auto-entitlements flag which skips the latest electron-osx-sign feature
electron-osx-sign "${APP}" --entitlements="mas.entitlements" --identity="${SIGNING_IDENTITY}" --no-pre-auto-entitlements

In mas.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>XXXXXXXXXX.net.mintkit.electron-quick-start</string>
    <key>com.apple.developer.team-identifier</key>
    <string>XXXXXXXXXX</string>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <array>
        <string>XXXXXXXXXX.net.mintkit.electron-quick-start</string>
    </array>
    <key>com.apple.security.network.client</key>
    <true/>
</dict>
</plist>

Sorry for my mistake in accepting that TeamID doesn't vary for one developer account... Actually it does. I haven't updated electron-osx-sign to use the actual _Team_ ID which here to be different from what could be parsed from your personal development identity. This should explain why electron-osx-sign doesn't work here @slaskis. We use --no-pre-auto-entitlements to skip all those quick automations introduced in 0.4.0.

I'm back with https://github.com/sethlu/electron-distribution-guide updated with guide for submission to the MAS. However, it's recommended to have the Development-signed Application running before moving onto Mac App Store Deployment. 😸

@sethlu I missed to mention that it works great for us now after updating to electron-osx-sign 0.4.0 with uploading to MAS. We've had a few releases accepted by Apple already.

So what we do is just use electron-packager to build the .app, then electron-osx-sign to sign all binaries, then after testing the sandboxed version we run electron-osx-flat to build a .pkg which we then upload with Application Loader.

We do however use a custom entitlements file and not the ones electron-osx-sign add:

<?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.com.ourapp</string>
    </array>
    <key>com.apple.security.files.user-selected.read-only</key>
    <true/>
    <key>com.apple.security.files.bookmarks.app-scope</key>
    <true/>
  </dict>
</plist>

@sethlu thanks for all your help. Signing with your script above, there no longer appear to be any flagrant errors in the console, however the app simply doesn't load (just a white screen)

In the console, nothing that would indicate errors:

11-6-2016 11:15:09.067 AM taskgated-helper[80923]: Starting taskgated-helper
11-6-2016 11:15:09.119 AM taskgated-helper[80923]: validated embedded provisioning profile: file:///Users/jan/workspace/MyApp.app/Contents/embedded.provisionprofile
11-6-2016 11:15:09.119 AM taskgated-helper[80923]: Found 1 provisioning profiles
11-6-2016 11:15:09.119 AM taskgated-helper[80923]: allowing entitlement(s) for pid=80922 due to provisioning profile
11-6-2016 11:15:09.439 AM MyApp Helper[80925]: GVA info: preferred scaler idx 0

Entitlements:

    <key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.application-groups</key>
<array>
    <string>*******EKS.com.me.myApp</string>
</array>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.application-identifier</key>
<string>******EKS.com.me.myApp</string>
<key>com.apple.developer.team-identifier</key>
<string>********EKS</string>
<key>com.apple.security.temporary-exception.shared-preference.read-only</key>
<array>
    <string>com.apple.symbolichotkeys</string>
</array>
    <key>com.apple.security.network.client</key>
    <true/>

Info.plist now contains the **EKS value.

Last time I saw something like this, the permissions on the files in the app (www component) were incorrect, however I've verified that they're set correctly. I've also tried with the network.server key being set to true, but still, just a white screen.

@slaskis Glad to hear! 😺 I'm pretty sure that apps signed with electron-osx-sign could run with at least electron-quick-start. May you have a check in Console and confirm if there be any errors like the following:

6/8/16 09:20:24.176 taskgated[472]: no application identifier provided, can't use provisioning profiles [pid=54551]

While testing [email protected], my app could launch without too much issue. However, I have received what shown above with the simple quick start app. Not sure if no application identifier provided could be slightly chronic.

@jpittner May I ask if your app now simply shows a white screen or literally freezes with a spinning cursor? I'm not quite sure if the app's failing dramatically after code-signed.

@sethlu just a white screen, no spinning cursor. In fact can access the App menu (which just has Quit) and can quit.

@jpittner The app should be launched correctly I think... May you try adding the following into your main.js, or equivalent, script someplace after the window's created, just to confirm some web page is shown?

mainWindow.webContents.openDevTools()

If the dev tools shows, the loaded page should be found somewhere in the panels. Otherwise we may have to think about some other resolutions to this issue.

@sethlu - looks like one of the node modules that's a required dependency is being ignored by electron-packager, the regex that used to work --ignore=.+\.o$ is now including anything that ends with o, rather than .o, which caused an uncaught javascript error (really need to look into how to handling those properly :) ) . changing it up to --ignore=.+\\.o$ fixed that, and it now works! 🎉

So now I guess the question is, from here, what do I need to change up to be able to submit it to the app store? I'm guessing I don't include the provisionprofile?

Thanks for all your help!

@jpittner 🎊 I would recommend checking out https://github.com/sethlu/electron-distribution-guide/blob/master/MacAppStoreDeployment.md. There are only some slight differences from the the workflow of Development signed-Application, basically substituting the certs and provisioning profiles. After doing that (as your app now runs properly), I believe your app is ready for submission! 😺
Let me know how it goes~

I believe we should use provisioning profiles (distribution while working on submission to the MAS) so that the app groups are allowed theoretically, and with less console complains.

From what I got back with Xcode, the inside of an app for distribution within the MAS should be something like:

And what looks like inside an app for distribution, however, outside the MAS should be something like:

I think we should have those provisioning profiles, which we have sneakily got around with earlier versions, just to be sure what comes out doesn't get too different from an Mac app made with Xcode.

@sethlu yeah there are a few logs like that:

11/06/16 20:55:53,971 taskgated[294]: no application identifier provided, can't use provisioning profiles [pid=97967]
11/06/16 20:55:57,000 kernel[0]: Sandbox: ExampleApp(97967) deny(1) mach-lookup com.apple.networkd

@slaskis Yea, these should be the error messages that come from Console while launching an app signed with the current [email protected]. I'm not very sure if they could mean anything wrong but the extra steps could resolve the identifier not found issue.

Actually, I first thought these messages lead to the an issue with app launching from @jpittner. However, it proved caused by something else.

If nothing prevents your app from launching anyway, it should be fine 😉, just the end user probably would received this in their Console as well...

now i am confused :)

• I've updated to latest electron mas prebuilt
• 0.4.0-beta4 of the electron-osx-sign
• updated plist-files as said in master branch
• read all this thread and @sethlu branch of the guide
• copied development (am i right?) provision profile into ./Contents folder in build script

still my app is able to pass first line of the ITS defence (it is on review now)

but yet when I run it I can see only icon and then it fails/quits (icon disappear)
and I can see console errors:

7/5/16 17:47:39.451 lsd[476]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist
7/5/16 17:47:39.480 taskgated[485]: no application identifier provided, can't use provisioning profiles [pid=84402]
7/5/16 17:47:40.453 sandboxd[35554]: ([84402]) Grape(84402) deny network-bind /private/var/folders/dr/cw1hncvj5vz4_p44q4nbjzgm0000gn/T/com.ChatGrape/S/SS

am I right that:

• app has ability to run on the apple side?
  
  
  
  • I've submitted version without copied dev profile, should I resubmit?
  
  
• app will have ability to run when it will be downloaded from app store if it will be accepted?
• should I do something else?

Hi @tyv I would like to clarify the presence of the guide: It is written as a solution for error message no application identifier provided, can't use provisioning profiles. If your app eventually passes the review at Apple, it should be fine to run after downloaded from the Mac App Store.

Here are a few cases and suggestions I have:

1. If the guide (https://github.com/sethlu/electron-distribution-guide/blob/master/MacAppStoreDeployment.md) is used to create a Mac App Store Deployment app, the app should not run because it is intended for submission.
2. If the guide (https://github.com/sethlu/electron-distribution-guide/blob/master/DevelopmentSignedApplication.md) is used to create a Development-signed Application, the app should not be submitted for review because we do not use 3rd party certs for signing here really.
3. If only signing with 3rd party certs without following any part of the guide (https://github.com/sethlu/electron-distribution-guide), the app should be running at launch with an error no application identifier provided, can't use provisioning profiles. If it doesn't, there should be issues that need resolving somewhere.

So if we happen to be with the first case, there's no need to worry too much at the moment I believe. However, if to be with the last case and the app doesn't launch properly, we may need to adjust the app slightly... The error message could be ignored like what others did I think; it's not a big trouble to have it as far as I've heard.

As your app is currently under review, I suppose we may just wait before iTC says anything.

It would be real neat if electron-osx-sign handled fixing up entitlements automatically /cc @sethlu

@paulcbetts isn't it is it? https://github.com/electron-userland/electron-osx-sign/blob/master/index.js#L160-L189

@sethlu thanks for the answer, I will report back.

@tyv I suspect a lot of people are getting caught up here: https://github.com/electron-userland/electron-osx-sign/blob/master/index.js#L155, which seems to require them to half fill-out their PList file. electron-osx-sign should just have a --mas option that does everything

@paulcbetts I'll revise a better code-signing flow later this week so it could adhere more to what Apple does. I've been thinking about integrating provisioning profiles to part of the signing flow for a while... Current what electron-osx-sign does is automating the entitlements file and the info plist if sandbox is enabled (by default or by the user input entitlement entry). If the user has an sandbox entry within a custom entitlements file, everything should work out fine currently.

@sethlu Remember, many node.js / web devs have no idea about PLists so, being Opinionated and just filling out everything for them from the package.json info might be A Better Thing (as long as people can opt-out and choose their own way of course) - I would assume the input Info.plist is junk / incorrectly configured and prioritize info in package.json as much as possible

To clarify @paulcbetts option you mention in https://github.com/electron/electron/issues/3871#issuecomment-230562216 is all what we need according to point 1 of @sethlu comment https://github.com/electron/electron/issues/3871#issuecomment-230532007 ?

Because after using it app doesn't run at all. Without it runs with blank screen. read below

Is there actually organised guide how to sign with using of electron-osx-sign that appreciate this issue?

Updated:

If anyone get problem of app not starting at all, because you read some files in home directory

http://jorgen.tjer.no/post/2011/07/26/home-relative-sandbox-entitlement/

Original comment:

And one more (only slightly off topic, but still with small overlap). I have read link given https://github.com/electron-userland/electron-osx-sign/wiki/3.-App-Sandbox-and-Entitlements which targets me to https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html

Does it mean that, if my app needs to read files like ~/.aws/credentials it can't be in sanbdox, therefore it can't be in App Store?

Have found that https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html

But trying

electron-osx-sign APP_PATH APP_PATH/Contents/Resources/app/node_modules/fsevents/build/Release/.node --mas --entitlements="com.apple.security.temporary-exception.files.home-relative-path.read-write"

Gives

Sign failed.
Command failed: codesign --sign 3rd Party Mac Developer Application: lukasz Sielski (ZZZZZZZZZ) -fv --entitlements com.apple.security.temporary-exception.files.home-relative-path.read-write APP_PATH
com.apple.security.temporary-exception.files.home-relative-path.read-write: cannot read entitlement data

Also I found now this http://electron.atom.io/docs/tutorial/mac-app-store-submission-guide/#additional-entitlements does it mean my com.apple.security.temporary-exception.files.home-relative-path.read-write has to be in parent.plist not in Info.plist. When using electron-osx-sign I haven't had parent.plist yet as it was created by it.

Hi @sielay,

Is there actually organised guide how to sign with using of electron-osx-sign that appreciate this issue?

The latest electron-osx-sign has not yet addressed provisioning profiles; however, after signing with the procedures (which could be done by electron-osx-sign) currently described in Electron docs, your app should launch and work as expected. Worth noting that there will be err messages like below thrown inside the Console.

7/5/16 17:47:39.451 lsd[476]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

After iTC submission, and eventually downloaded from the MAS, it is uncertain if this err log will disappear; iTC resigns your app for MAS distribution on Apple's server so those downloading your app could run it without Gatekeeper prompts.

Does it mean that, if my app needs to read files like ~/.aws/credentials it can't be in sanbdox, therefore it can't be in App Store?

Your app may not access ~/.aws/credentials for that the location is inaccessible without temporary exceptions in your entitlements file.

But trying

electron-osx-sign APP_PATH APP_PATH/Contents/Resources/app/node_modules/fsevents/build/Release/.node --mas --entitlements="com.apple.security.temporary-exception.files.home-relative-path.read-write"

Gives

Sign failed.
Command failed: codesign --sign 3rd Party Mac Developer Application: lukasz Sielski (ZZZZZZZZZ) -fv --entitlements com.apple.security.temporary-exception.files.home-relative-path.read-write APP_PATH
com.apple.security.temporary-exception.files.home-relative-path.read-write: cannot read entitlement data

Please create a custom entitlements file if wish to mark additional entitlement entries. I would recommend create app.entitlements or app.plist, which really is just the parent.plist mentioned in your post I think, with the following contents as a basis:

<?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.temporary-exception.files.home-relative-path.read-write</key>
    <array>
      <string>/.aws/</string>
    </array>
  </dict>
</plist>

Then you may sign your app bundle with the following command:

electron-osx-sign APP_PATH APP_PATH/Contents/Resources/app/node_modules/fsevents/build/Release/.node --entitlements="path/to/my.entitlements"

For --entitlements you may provide app.entitlements or app.plist, which is essentially your custom entitlements file. (Sorry but we cannot yet directly input entitlement entries to electron-osx-sign for processing.)

Additionally, to confirm your codesigning procedure being correct, you may turn on debugging for electron-osx-sign with:

export DEBUG=electron-osx-sign*

And then use electron-osx-sign to code sign your app bundle.

Let me know if there be any confusions. 😸 A next revision of electron-osx-sign may be more useable with easier customizations I think.

@sethlu as I said, my app after being signed can't run and exit after launch, same things happen and on App Store reviews.
and sandboxing is still rise questions from App Store, here is answer:

Performance - 2.1
We noticed that with a valid receipt installed, your app quits on launch. The Console reports the app "Exited with exit code: 173" and the OS states the app "is damaged and can't be opened". This generally indicates that the app is not verifying its receipt correctly.

Next Steps
Please revise your app and test it to ensure that it runs as expected.

Performance - 2.4.5

We've determined that one or more temporary entitlement exceptions requested for this app are not appropriate and will not be granted:

com.apple.security.temporary-exception.sbpl - (allow mach-lookup (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))

We understand this may prevent the app from being approved for the Mac App Store. We encourage you to investigate other ways of implementing the desired functionality.

Hi @tyv,

We noticed that with a valid receipt installed, your app quits on launch. The Console reports the app "Exited with exit code: 173" and the OS states the app "is damaged and can't be opened". This generally indicates that the app is not verifying its receipt correctly.

I think we may need to start tweaking the app a bit before resubmitting it to iTC.

We've determined that one or more temporary entitlement exceptions requested for this app are not appropriate and will not be granted:
com.apple.security.temporary-exception.sbpl - (allow mach-lookup (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))

I'm quite sure though that this temporary exception fix is no longer in use after the introduction of application groups by setting ElectronTeamID in Info.plist and a corresponding entry in the entitlements file.

Would you display your custom entitlements used for signing below? And if using electron-osx-sign, would you paste a copy of the logs emitted with env export DEBUG=electron-osx-sign* as well? Let us know if there be additional assets for your code signing.

I think we may need to start tweaking the app a bit before resubmitting it to iTC.

don't understand you

Would you display your custom entitlements used for signing below?

here you can find plist's I use while packing app https://github.com/ubergrape/grape-electron/tree/master/resources/osx

And if using electron-osx-sign, would you paste a copy of the logs emitted with env export DEBUG=electron-osx-sign* as well?

I use it js api
here is setup: https://github.com/ubergrape/grape-electron/blob/master/tasks/release/osx.js#L91

@sethlu here is debug log https://gist.github.com/tyv/d96a11c5fde73e3966b0014311a3079f

the main concern is, after I sign app (in different ways without any errors), it is unable to run it.
it self closes itself.

@tyv, I think your app is well signed. May you check in the Console as well to see if any error arises when your app launches? Also, I would recommend removing the temporary exception in https://github.com/ubergrape/grape-electron/blob/master/resources/osx/child.plist#L9-L10 before building another testing release.

@sethlu
i see only

7/26/16 13:36:49.427 sandboxd[19719]: ([20302]) Grape(20302) deny network-bind /private/var/folders/dr/cw1hncvj5vz4_p44q4nbjzgm0000gn/T/com.ChatGrape/S/SS

@sethlu here is full report https://gist.github.com/tyv/347298b455b560ea9721cf8ff09d0fe8

and one more

7/26/16 13:54:54.241 taskgated[509]: no application identifier provided, can't use provisioning profiles [pid=20987]

@sethlu it looks like it is same as here: electron-userland/electron-osx-sign/issues/59
any update on that problem?

Hi @tyv, apologies for my late reply; I've been away for the past few days.

The issue https://github.com/electron-userland/electron-osx-sign/issues/59 I think is slightly different in the way that a critical problem lies on the video en/decoder. (However, I don't know how @jpittner got around the video en/decoder issue... Or just following the conceptual signing flow at https://github.com/sethlu/electron-distribution-guide then everything just naturally resolved.)

The app should still launch with no application identifier provided... and without significant effects as far as I have heard 😕. So far I believe with your app correctly signed, the only signage is really only deny network-bind... Let me have a check for a resolution.

@The video decoder/encoder stuff went away once the package was properly signed. Right now, I've got it working with MAS build (and can use a development provisioning profile to test it) but am having some trouble getting the developer-id signed version (that is, for non-MAS distribution) to work properly!

edit - spoke too soon. That was with prior version (1.2.x) with 1.3.1 I'm now running into problems getting the MAS build to load up on my development machine.

@tyv I've managed to investigate a bit more over the past few days... Apple sandbox does not allow network-bind outside sandboxed containers but I am not sure what actually caused your app to have such behavior. Have you tried to create sockets in your code?

@jpittner Thanks for the info! I will have a look at the latest MAS builds.

@sethlu by sockets you also include websocket?

@sethlu

Have you tried to create sockets in your code?

all this app does is change location.href to the https://... where is web app is and this app yes, opens websocket connection.

@kof About web socket, from the text network-bind I think it does not matter much as long as it does not touch critical areas about binding essentially I guess?

Network-bind
Syntax: Actions: Filters: Modifiers:
(action network-bind [filter] [modifier]) allow deny
network path file-mode
send-signal no-log
Definition:
Control access to socket bind(). It has no support for IP filtering, it must be localhost or * (check network filter for more information).
Applies to:
bind, unp_bind
Example(s):
(deny network-bind (local ip "*:7890"))
$ sandbox-exec -f ls2 nc -l 7890
nc: Operation not permitted
Log output:
Sep 2 21:08:41 macbox sandboxd[45438]: nc(45437) deny network-bind 0.0.0.0:7890

Ref: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf

so maybe it is the web sockets from non-localhost domain?

@tyv Have you tried to add com.apple.security.network.client in the app(/parent) entitlements file? Sorry I'm not sure if it may work for that I have not encountered similar cases.

<?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.network.client</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <string>Y8DPE6DGC7.com.ChatGrape</string>
  </dict>
</plist>

I'll try

I am able to run empty app after sign.
Will try to find what cause problem and will report back.

okay, I found what kills app when it is signed
http://electron.atom.io/docs/all/#appmakesingleinstancecallback
shouldQuit === true in this example from old official doc:

const shouldQuit = app.makeSingleInstance(() => {
  const {mainWindow} = state
  // Someone tried to run a second instance, we should focus our window
  if (mainWindow) showMainWindow()
  return true
})

if (shouldQuit) quit()

@sethlu it is same with new snippet from the doc

@tyv does you app work now?

I removed that code and yes, but yet didn't have time to check whats wrong with that method
why it is always returns true when app is signed

On Aug 7, 2016, at 12:06, Zhuo Lu [email protected] wrote:

@tyv does you app work now?

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

@tyv A couple of places I think where this issue occurs:

1. https://github.com/electron/electron/blob/91169396f6b631e823c5fe2c7a0865b41347f2c1/atom/browser/api/atom_api_app.cc#L426-L431
2. https://github.com/electron/electron/blob/99ec841a8e4fe21182e2dfa7a1f085d70b80d6cf/chromium_src/chrome/browser/process_singleton_posix.cc#L881-L902
3. https://github.com/electron/electron/blob/99ec841a8e4fe21182e2dfa7a1f085d70b80d6cf/chromium_src/chrome/browser/process_singleton_posix.cc#L740-L754

Seems that Electron does open a socket and send out a message checking process singleton... I'm not yet sure how to avoid having the network binding be addressed in sandbox though.

okay, i see, so if this isn't fixable, probably comment in guide is a good idea.

or default value should be false, and still comment near the method doc, would be nice

Why would this not be fixable? It's our code - can you file a separate bug?

@paulcbetts here you go ^^^

Hi,
Not fix at all, even with a simple HelloWorld. Anyone have an idea of what needs to be done to sumbit my app to Mac Store (the build is working nicely when not signing the app).

electron-packager . "MyApp" --platform=mas --arch=x64 --overwrite --version=1.4.4 --app-bundle-id="com.mycie.myapp" --app-version="1.0.0" --build-version="666"

electron-osx-sign "MyApp.app" --entitlements="mas.default.entitlements" --entitlements-inherit="mas.inherit.default.entitlements"

electron-osx-flat "MyApp"

mas.default.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.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.network.server</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <string>XXXXXXXXXXX.com.mycie.myapp</string>
  </dict>
</plist>

mas.inherit.default.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.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.inherit</key>
    <true/>
  </dict>
</plist>

electron-osx-sign:warn No `platform` passed in arguments, checking Electron platform... +0ms
  electron-osx-sign:warn No `identity` passed in arguments, discovering identities... +3ms
  electron-osx-sign Signing application... +1s
  electron-osx-sign > application         MyApp-mas-x64/MyApp.app +0ms
  electron-osx-sign > platform            mas +0ms
  electron-osx-sign > entitlements        ../mas.default.entitlements +0ms
  electron-osx-sign > child-entitlements  ../mas.inherit.default.entitlements +0ms
  electron-osx-sign > additional-binaries  +1ms
  electron-osx-sign > identity            3rd Party Mac Developer Application: BAYARD PRESSE (VE4JH2R5J4) +0ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app/Contents/MacOS/MyApp Helper EH +117ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app +130ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app/Contents/MacOS/MyApp Helper NP +120ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app +119ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper +121ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app +119ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework +122ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib +1s
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib +152ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework +318ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/MacOS/MyApp +1s
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Resources/app/PepperFlashPlayer.plugin/Contents/MacOS/PepperFlashPlayer +599ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app +410ms
  electron-osx-sign Verifying sign... +612ms
  electron-osx-sign Verifying entitlements... +278ms
Application signed: MyApp-mas-x64/MyApp.app

I'm facing this issue, what is the solution?
When
com.apple.security.app-sandbox is in my plist - my app gets whitescreen.