MAS com.apple.security.app-sandbox in entitlements crashes the application

[danutzcodrescu]

• Version: 22.4.1

• Target: mas

Sandbox entitlement is crashing the mas build on startup. The application works fine if I do not include <key>com.apple.security.app-sandbox</key><true/>, but it is refused by Mac Store. I tried using both mac and mas plist.

I even tried a workaround proposed in [https://github.com/electron/osx-sign/issues/192](this issue) to add to node_modules/app-builder-lib/templates/entitlements.mac.plist the sandbox entitlement. The app crashes.

Here is my build config:

 "build": {
    "productName": "xxxxx",
    "appId": "com.xxx.xx",
    "artifactName": "${productName} Setup-${version}.${ext}",
    "mac": {
      "entitlementsInherit": "build/entitlements.mac.plist",
      "category": "public.app-category.business",
      "extraResources": [
        {
          "from": "./preconfigMac",
          "to": "preconfig",
          "filter": [
            "*.sh"
          ]
        }
      ]
    },
    "directories": {
      "output": "release"
    },
    "files": [
      "dist/",
      "package.json"
    ],
    "protocols": {
      "name": "Test protocol",
      "role": "Viewer",
      "schemes": [
        "test"
      ]
    },
    "mas": {
      "type": "distribution",
      "provisioningProfile": "embedded.provisionprofile",
      "entitlements": "build/entitlements.mas.plist",
      "entitlementsInherit": "build/entitlements.mas.inherit.plist"
    },
    "afterSign": "scripts/notarize.js"
  },

I identified the problem by checking the entitlements of the output. It seems that when I add sandbox entitlement it completely messes up the xml.

Here is the output of codesign -d --entitlements :- Test.app when entitlements do not include sandbox:

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

That is exactly the xml that I have in my entitlements.mas.plist.

However, when I add the sandbox entitlement to mas.plist or to mas.inherit.plist, this is the output:

Executable=xxxxx
bplist00?
                _ com.apple.application-identifier_#com.apple.developer.team-identifier_com.apple.security.app-sandbox_%com.apple.security.application-groups_com.apple.security.cs.allow-jit_6com.apple.security.cs.allow-unsigned-executable-memory_0com.apple.security.cs.disable-library-validation_xxxxxx	?       	       :`???7U`acdef%  

As you can see the entitlements are completely messed up because of the sandbox. Seems that there is some issue in how the entitlements are created during the build.

Any suggestions of what might be wrong?

[werber]

I have identical issue with identical setup. Also I can change entitlements to anything I want and all works except the case when I enable app-sandbox in entitlements. Tried building for mas-dev and mas with different provision profiles and certificates. Any updates on this?

[greenimpala]

Having the exact same issue here too. Add com.apple.security.app-sandbox and the built app will not launch.

[schetle]

The reason the entitlements gets "messed up" is because your entitlements are being regenerated with extra fields, and then binary encoded. This only occurs when com.apple.securirty.app-sandbox is supplied in your entitlements, and is caused by util-entitlements.js in electron-osx-sign.

I'm currently unsure why this process takes place, because my native (non-electron) macOS apps don't have any of the extra stuff electron-osx-sign is adding to the entitlements, and further they are not in the encoded format being used here.

[greenimpala]

@schetle yep I think you're right. See electron/osx-sign#223 (comment) for reversal of this binary encoding.

[runofthemillgeek]

@schetle doesn't the binary encoding stem from the app-builder-bin package and not osx-sign?

[schetle]

@sangeeth96 The originating call for the entitlements (specifically the parent entitlements) getting encoded is in the preAutoEntitlements code in util-entitlements.js from the dependent electron-osx-sign package. The code can be seen on line 88 of util-entitlements.js. It is calling into appBuilder to perform the operation, it looks like, but you can prevent entitlements from getting encoded by preventing the call altogether.

Bypassing that whole section of electron-osx-sign will prevent your entitlements from getting encoded. Take a peek at the file for confirmation of this.

[mahnunchik]

It seems it is related:

• App sandbox not enabled (ITMS-90296): For other binaries to be signed electron/osx-sign#192
• MAS build crashing on launch: Namespace SIGNAL, Code 0x4 electron/osx-sign#223
• App Store build succeeded but no window shows due to "out of memory" electron/electron#20560
• Also there is a mistake in the documentation Wrong documentation: default entitlements and entitlementsInherit #4956

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mahnunchik]

Of course it is relevant! Fucking slate bot! сб, 11 июл. 2020 г., 17:04 stale[bot] <notifications@github.com>:

…

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4790 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF6VB7C3KK5O6TUXY36HTTR3B5PBANCNFSM4LMJ4WXQ> .

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[danutzcodrescu]

It is relevant and no solution is provided...

[johannesjo]

One of the many critical issues solved by the great stale bot! 🥳

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mahnunchik]

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mahnunchik]

#4790 (comment)

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[danutzcodrescu]

no fix yet...

[Taz-Bizeloper]

I had this issue but found out that it was because I was using requestSingleInstanceLock() in the main.js file and this was crashing the mas-dev build when setting sandbox in the entitlements

electron/electron#15958

[czzonet]

The mas-dev runs well after I install the correct provisionprofile. My crash info was 'EXC_CRASH (Code Signature Invalid)'.

"electron-builder": "22.10.5"

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mahnunchik]

#4790 (comment)

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[danutzcodrescu]

#4790 (comment)

[devon2018]

☝️

[hisnameisjimmy]

I'm still running into this exact issue. How do we fix this?

[fatemehmarzoughi]

Same here (

[gregoiregentil]

I have the same issue. Is there a basic entitlement file working somewhere?

[tylerlong]

I had been stuck on this issue for 2-3 days and finally I made it work!
Let me share the keys with your guys:

Put *.plist files and *.provisionprofile files in the root of build/ folder

I didn't do that, and my app quit right after I saw a window and no error was thrown.

Install the *.provisionprofile file

I generated a *.provisionprofile file and I told electron-builder where it is.
But I didn't double click to install it to my operating system.
I spent almost a day before I realized that I needed to install it.

There are lots of mistakes that you can make. The two above are the ones that cost me most time.

[gregoiregentil]

On my side, this issue #7229 helped me to resolve the problem.

[mordom0404]

Thank you so much for your solution here, this solved a problem that had been bugging me for weeks, especially the second point.
It should be pointed out that the plist file and provisionprofile file can be placed anywhere, as long as it can be referenced normally, not necessarily in the ./build folder
Regarding the second point, it took me 2 days to successfully install this provisionprofile into the system, until I found this link: "Provisioning profile does not allow this device." Mac mini M1
The key point is that both your mac's UUID and UDID should be added to apple developer's device id list, and make sure they both exist in the provisionprofile.
At this point, my mas-dev can finally run normally.
Hope these experience can help latecomers and thank you again.

I had been stuck on this issue for 2-3 days and finally I made it work! Let me share the keys with your guys:

Put *.plist files and *.provisionprofile files in the root of build/ folder

I didn't do that, and my app quit right after I saw a window and no error was thrown.

Install the *.provisionprofile file

I generated a *.provisionprofile file and I told electron-builder where it is. But I didn't double click to install it to my operating system. I spent almost a day before I realized that I needed to install it.

There are lots of mistakes that you can make. The two above are the ones that cost me most time.

[p3x-robot]

anyone fixed this? I have sandbox but it quits.