The Mac App store now rejects all Electron versions less than v5 (meteor-desktop only supports up to v4) #261
Comments
LDubya
changed the title
|
Hi @LDubya, If you need builder and watcher, you can use config below to change Meteor plugins directory: |
|
Hi @darqs, I'm getting an error with a fresh install of Meteor's "simple todos" app. Specifically, either it doesn’t install (first example), or I can get it to install but it will crash upon startup after packaging as a .app and signing. First example
meteor create simple-todos
cd simple-todos
leads to the following error: npm ERR! code ENOENT
npm ERR! syscall chmod
npm ERR! path /Path/To/simple-todos/node_modules/meteor-desktop/dist/bin/cli.js
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, chmod '/Path/To/simple-todos/node_modules/meteor-desktop/dist/bin/cli.js'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoentand the package is not added to package.json, and the build script is also not added to package.json. I also tried...downloading the master branch, renaming it to npm ERR! path /Path/To/simple-todos/node_modules/meteor-desktop/dist/bin/cli.js
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall chmod
npm ERR! enoent ENOENT: no such file or directory, chmod '/Path/To/simple-todos/node_modules/meteor-desktop/dist/bin/cli.js'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoentIgnoring that error and running but of course the package is not added to package.json, and the build script is also not added to package.json. running
and when viewing simple-todos/package.json, there is a going back to the meteor app's root directory and running but this causes /meteor-desktop to be removed from /node_modules, and I have to start all over again from the start. I do that again and end up back here. But of course Changing the meteor run script to be
And the desktop script to be However, it doesn't sign and run. If you build a signed .app as a sandboxed app and try to run the .app (with the proper credentials and profiles from App Store Connect), the app just crashes on startup, giving the error: @darqs any ideas why the app doesn't run after signing? These are the same credentials and profiles that worked with electron v4. |
|
Update: I've tried it using the This is with a vanilla install of Meteor's Opening up the Mac's console and looking at the crash log, it says So it looks like this may be due to a binary that wasn't signed? What do you think? In the .desktop/settings.json, I am using the following for the mac build settings: So it should be including those entitlements. entitlements.mas.plist: entitlements.mas.inherit.plist: |
|
Same app-sandbox issue also exists with Electron 6.1.7. |
|
I think |
|
Is there a way to disable the meteor app's attempt to start a local server? Our meteor app doesn't need to connect to a remote server, it's entirely client-side. No remote connection, using Ground DB as the local database. So including an entitlement to enable a server will lead to an App Store rejection. If we could disable meteor even attempting to start a local server, I think it may run sandboxed. Not sure if this is on meteor (maybe remove/modify a package?) or on Electron (maybe there’s a flag that can be set?) |
|
Update: stripped down Meteor to bare minimum packages, removing packages that may attempt to make a remote connection. Stripped-down version of Meteor does not have an effect. Issue still remains. Packages used:
List of Meteor packages removed (while still enabling the app to run): So I'm not sure if removing Meteor packages that may attempt to make remote connections is the way to go. There's probably an Electron setting somewhere.. |
|
I think local server is required, because it provides client files. |
|
K I'm giving it a shot submitting with the 'server' and 'client' entitlements. Hoping that the app store reviewer understands that there are no server connections besides the self-consuming local server that the app spins up. |
|
I'm stuck in the same boat, and getting the same crash. It's been over a year, and I might go crazy soon. FWIW, there is a fork of I downgraded it to Electron 5.0.13, which should be patched for the private APIs. The v6 release runs three new GPU helper instances, so I avoided it because there appear to be other code signing bugs there. However, even with v5 even getting the DMG to run seems to be a hit or miss, even with code signing disabled. -- FWIW, I had found a few patches that have helped: |
|
I have noticed that the application makes a request for a file using a relative path, which is outside of the application bundle. I wonder if that's where the sandbox problem is kicking in. Probably, this is a bug with Also, it's also getting a lot of denial for files that are with-in app 🤔 |
|
@LDubya any luck with the client and server entitlements? |
|
@msavin I was able to get the app to run with the entitlements, but am still in App Store Review limbo. They questioned the server entitlement. I wrote a response, but I also removed the client entitlement since the app still runs without it. 4 days ago they said to add the client entitlement metadata in App Store Connect but do not submit a new build, just leave a comment. I do that and then a whole 3 days later they come back and say I need to submit a new build (yep it took them 3 days to write one a sentence response that directly contradicts what they wrote previously). This is ridiculous. I still don’t know whether the server entitlement will be approved — the app doesn’t make any remote connections. |
|
@msavin well. this is beyond frustrating. While signing, the package adds the "com.apple.security.application-groups" entitlement, even though it's not listed anywhere in our entitlements files. Because of this, the app is getting rejected (and we can't come to any conclusion about the client/server entitlements yet). Since that entitlement is not included in our entitlement plist files, we're not sure where it's being set, and so we don't know how to prevent the packager from including that entitlement. Any ideas? |
|
Yes set it as team ID and bundle ID. For example:
<key>com.apple.security.application-groups</key>
<string>TEAM_ID.com.company.appname</string>
…Sent from my iPhone
On Jan 20, 2020, at 10:08 PM, L ***@***.***> wrote:
@msavin well. this is beyond frustrating. While signing, the package adds the "com.apple.security.application-groups" entitlement, even though it's not listed anywhere in my entitlements files. Because of this, the app is getting rejected. Since it's not included in our entitlement plist files, we're not sure where it's being set, and so we don't know how to prevent the packager from including that entitlement. Any ideas?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@msavin that is how it's set. Specifically, it's TEAM_ID.appID, exactly how this package sets it when you tell it to build for mas. We're not using a third-party app to sign it. The problem is, it looks like Apple wants it gone. And we don't know how to prevent it from being included. It's being included as an entitlement even though we don't set it in our entitlement plist files. Also, Apple's instructions are confusing, because they say we should be able to edit this metadata inside of App Store Connect and not submit a new build, but there is nowhere to remove entitlements that we can find using the interface. |
|
🤯
… On Jan 20, 2020, at 11:30 PM, L ***@***.***> wrote:
@msavin that is how it's set. Specifically, it's TEAM_ID.appID, exactly how this package sets it. We're not using a third-party app to sign it. The problem is, it looks like Apple wants it gone.
Guideline 2.4.5(i) - Performance
Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary.
"com.apple.security.application-groups"
Next Steps
For information on common app sandboxing issues, please see Technical Q&A QA1773 Common app sandboxing issues.
See App Sandboxing for links to essential video and documentation to learn how to sandbox your application.
Should you need code-level assistance implementing sandboxing, contact Apple Developer Technical Support.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Is it in your settings.json file for electron? Probably, electron installer or Meteor-desktop is configuring it from there.
…Sent from my iPhone
On Jan 20, 2020, at 11:59 PM, Max Savin ***@***.***> wrote:
🤯
>> On Jan 20, 2020, at 11:30 PM, L ***@***.***> wrote:
>>
>
> @msavin that is how it's set. Specifically, it's TEAM_ID.appID, exactly how this package sets it. We're not using a third-party app to sign it. The problem is, it looks like Apple wants it gone.
>
> Guideline 2.4.5(i) - Performance
>
>
> Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary.
>
> "com.apple.security.application-groups"
>
> Next Steps
>
> For information on common app sandboxing issues, please see Technical Q&A QA1773 Common app sandboxing issues.
>
> See App Sandboxing for links to essential video and documentation to learn how to sandbox your application.
>
> Should you need code-level assistance implementing sandboxing, contact Apple Developer Technical Support.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Nope, it's not in any of our settings file. A grep returns nothing of the sort. We only set the sandboxed keys:
But when the app is built, the main app includes the following keys (additional ones are in bold)
So it adds entitlements that we don't tell it to. Specifically the following file will force-add the application-group entitlement. /node_modules/app-builder-lib/electron-osx-sign/util-entitlements.js the specific lines of code are: // Init entitlements app group key to array if not exists
if (!entitlements['com.apple.security.application-groups']) {
entitlements['com.apple.security.application-groups'] = []
}
// Insert app group if not exists
if (Array.isArray(entitlements['com.apple.security.application-groups']) && entitlements['com.apple.security.application-groups'].indexOf(appIdentifier) === -1) {
debuglog('`com.apple.security.application-groups` not found in entitlements file, new inserted: ' + appIdentifier)
entitlements['com.apple.security.application-groups'].push(appIdentifier)
} else {
debuglog('`com.apple.security.application-groups` found in entitlements file: ' + appIdentifier)
}This is also not documented anywhere that I could find, besides a github issue chat where the conversation was about unanimously deciding to add this functionality. Which makes me wonder if it's actually supposed to be there and my Apple reviewer needs an explanation, not for me to remove it. And if that's the case then this should be documented somewhere so that anyone submitting for MAS will know to include that explanation. |
|
Yeah this is ridiculous. Preventing the entitlement from being included (by removing that block of code) prevents the app from running on startup. Electron seems to need it in order to run sandboxed. |
|
K, Approved with the following entitlements on Electron 5.0.13 uploaded as a .pkg (the .app should properly run locally even after code signing for mas). Entitlements
If you're not making remote connections you need to explain the requirement for the server and client entitlements due to the way electron SDK sets up a local server for self-consumption while the app is running. You need to explain the requirement for the application-groups entitlement due to Electron SDK’s need for using the Mach IPC, which is not normally available to a sandboxed app but is made available via the application-groups entitlement. Don’t explain those things and lose weeks going back and forth during review and being told you’re incorrectly implementing sandboxing or using more entitlements than you need. @darqs maybe this should be documented somewhere? |
|
@LDubya are you setting all these in |
|
@darqs now that 2.2.5 is out, do you still recommend using your branch? |
|
@msavin Hi, version 2.2.5 should work with Electron >= 7.1.10 || >= 8.0.0. My branch fix some issue for Electron 7.1.8, but now it is not required. |
|
Hey @msavin, that's the final output. You can scan a .app to find its lists of entitlements. Within the meteor-desktop settings, some are set in entitlements.mas.plist, helpers plist, etc. Others are set automatically by the builders. I can send you sample plists if needed. Would love to get some help from someone with this other issue though: #265 |
|
@LDubya if you can send the sample plists, along with any code changes you had to make to meteor-desktop/etc, that would be great. I have gone through ten builds already and I think the App Store people are starting to get annoyed. |
|
barebones: AppRoot/.desktop/entitlements/entitlements.mas.plist <?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/>
</dict>
</plist>AppRoot/.desktop/entitlements/entitlements.mas.inherit.plist <?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>And in your AppRoot/.desktop/settings.json {
... (name, version, etc)
"builderOptions": {
...
"appId" : "Your App Bundle ID",
"mac": {
... (icon, etc)
"type" : "distribution",
"target" : "mas",
"entitlements" : ".desktop/entitlements/entitlements.mas.plist",
"entitlementsInherit" : ".desktop/entitlements/entitlements.mas.inherit.plist",
"hardenedRuntime" : false,
"identity" : "Your Developer Identity"
},
}
}Make sure the script is in your AppRoot/package.json {
"scripts": {
...
"desktop": "meteor-desktop"
}
},Have all the necessary app signing certificates installed on your machine, XCode, etc. Run the following to build and sign and package npm run desktop -- build-installer --mac;Should output .app and .pkg in AppRoot/.desktop-installer/mas |
|
@LDubya thank you, that was very helpful. Are you passing in anything for Here's what my configuration looks like, going to try again this week. Please let me know if you spot any issues. settings.json "mac": {
"type": "distribution",
"icon": "logo.icns",
"extendInfo": {
"ElectronTeamID": "XXX",
"com.apple.developer.team-identifier": "XXX",
"com.apple.application-identifier": "XXX.com.corp.app",
"com.apple.security.application-groups": "XXX.com.corp.app"
},
"entitlements": "entitlements.mas.plist",
"entitlementsInherit": "entitlements.mas.inherit.plist",
"provisioningProfile": "embedded.provisionprofile",
"target": ["mas"],
"bundleVersion": "10",
"hardenedRuntime": false
}entitlements.mas.plist <?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.server</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
</dict>
</plist>entitlements.mas.inherit.plist <?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> |
Nope. Full mac for us is: "mac": {
"icon": ".desktop/assets/MyIcon.icns",
"type" : "distribution",
"darkModeSupport": true,
"target" : "mas",
"entitlements" : ".desktop/entitlements/entitlements.mas.plist",
"entitlementsInherit" : ".desktop/entitlements/entitlements.mas.inherit.plist",
"hardenedRuntime" : false,
"identity" : "REDACTED"
}Your provisioning profiles and other credentials should be installed on your device's keychain, registered on App Store Connect, and will be pulled automatically during signing. Try the barebones config and see what happens during packaging and signing. This is on Electron v5 btw. We're migrating to V6 now, though, and looks like we're running into some build upload issues on the App Store, with the build no longer passing their automated integrity checks. |
|
@LDubya awesome, thanks. By the way, it looks like Electron 8 has been patched for MAS |
|
Can confirm 8.0.2 can be published to Mac App Store with above instructions and the workaround posted here. |
|
@msavin @LDubya we made fork here sharekey/meteor-desktop or npm using our repo you will have no problems with the latest version of electron and no need for any workaround |
|
@msavin and @linegel , we've been making updates to the desktop app for the first time in a couple years. It looks like Apple is making it hard to test MAS builds locally, so when we build for MAS, the app doesn't load. This makes it hard to test the production build, which is under tighter restrictions. How are you guys able to test your MAS builds before submitting to Apple? We tried the @sharekey/meteor-desktop build, and can't seem to find a setting to allow for testing production MAS builds. |
Submitting an app with Electron v4 results in a rejection citing the use of private APIs, discussed here (electron/electron#20027). It was patched in Electron v5 and v6, but not in any version of v4. If meteor-desktop can't support electrion v5, v6, or a fork of v7 that has been patched to fix this issue, then meteor-desktop can't be used to submit apps to the Mac App Store anymore.
I'm also citing this issue (#238), which is similar but supporting Electron v5 (^5.0.13) would also address this.
The text was updated successfully, but these errors were encountered: