Electron is not able to pass App Store verification #5350

Closed
bryan-jowers opened this Issue Apr 29, 2016 · 14 comments

Projects

None yet

4 participants

@bryan-jowers
bryan-jowers commented Apr 29, 2016 edited

@zcbenz From bd406ab there was a change instructing com.apple.security.temporary-exception.sbpl is now needed.

After 5 days in review, my app was just rejected:
screen shot 2016-04-29 at 2 07 21 pm

I provided the following explaination during 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]+$"))

Do you have any advice? This recent change renders Electron no longer an option for my product if we want to be in the AppStore. I'm sure I am not the only person who has encountered this issue.

@zcbenz
Contributor
zcbenz commented Apr 30, 2016

Unfortunately you have to use it if you want to use recent versions of Electron, it is a change made in Chromium and we are not able to revert that. The only solution is to try to convince the reviewers of Mac App Store to approve the usage of com.apple.security.temporary-exception.sbpl.

@zcbenz zcbenz closed this Apr 30, 2016
@bryan-jowers

Thanks for the reply. Do you have any suggestions on how to convince them? Otherwise my only option is using a previous version of electron, correct? What's the latest version that wouldn't require this permission?

@zcbenz
Contributor
zcbenz commented Apr 30, 2016

v0.35.x doesn't have this limitation, I have no idea how to convince them. :(

@MarshallOfSound
Member

If only you could tag @apple 👍

@paulcbetts paulcbetts reopened this May 13, 2016
@paulcbetts paulcbetts changed the title from com.apple.security.temporary-exception.sbpl to Electron is not able to pass App Store verification May 13, 2016
@paulcbetts
Contributor

Resurrecting this as the catch-all bug for getting Electron into MAS

@zcbenz
Contributor
zcbenz commented May 14, 2016

@paulcbetts The problem is, the com.apple.security.temporary-exception.sbpl rule is a must-have for Electron, rewriting Chromium's IPC system is basically impossible work. So it makes this issue just unable to be resolved.

The only thing we can do, is to rename the org.chromium.Chromium.rohitfork.[0-9]+ mach channel to something like com.yourcompany.yourapp.rohitfork.[0-9]+, but I don't know whether it makes things better or worse. We really need to know how the reviewers of Mac App Store think.

@paulcbetts
Contributor
paulcbetts commented May 14, 2016 edited

@zcbenz After some digging, it looks like we might be able to resolve this:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html

Normally, sandboxed apps cannot use Mach IPC, POSIX semaphores and shared memory, or UNIX domain sockets (usefully). However, by specifying an entitlement that requests membership in an application group, an app can use these technologies to communicate with other members of that application group.

Mach port names must begin with the application group identifier, followed by a period (.), followed by a name of your choosing.

So it looks like the best way to fix this is to make the Mach channel lookup the channel prefix from Info.plist. The good news is that it pretty clearly states that we can use Mach ports, so if anyone gets rejected from the store for it we've got a pretty good leg to stand on for complaining about it / getting the rules changed

@paulcbetts
Contributor

Even better, we don't have to patch Chromium to do this:

  1. MachBroker::GetMachPortName calls
  2. base::MachPortBroker::GetMachPortName, which is configured by
  3. base::BaseBundleID which can just be get/set
@zcbenz
Contributor
zcbenz commented May 15, 2016

@paulcbetts Cool, I'll make a change of the mach port name and see how it goes.

@bryan-jowers

@paulcbetts Do we have an action to resolve this issue? I'm still sitting on an app that I can not pas MAS review. Thanks for digging into this...

@zcbenz zcbenz self-assigned this May 17, 2016
@zcbenz zcbenz closed this in #5584 May 18, 2016
@paulcbetts
Contributor

@bryan-jowers Peep #5584 and let us know if this works (once this change hits a released version)

@bryan-jowers

@paul @zcbenz Good news guys. I really appreciate all the effort on this issue. I submitted my app yesterday afternoon and today it was approved by Apple. We made it! :)

I do have a question. Before, my app was around 100 MB. Now, the package is 413 MB. Installed, it boats to 1G! The app is 1G! that's huge. My app is 1 small file that loads a website. So the size does not come from my app.

Any thoughts on this.

But - thanks again for solving MAS!

@paulcbetts
Contributor

@bryan-jowers I think some of your symlinks are getting turned into copies maybe? This is pretty common on OS X, usually it's from trying to package on non-OS X (esp Windows)

@bryan-jowers

Here is what I discovered. Through lots of testing I ended up building quite a number of builds. I am on a Mac, and generating builds for Windows, Mac and Linux I had a number of directories and builds. When I would package, it would generate the app.asar and the size would be huge. 350MB huge (normally its <1 MB). When I deleted the other directories with the other builds, the size would slowly go down. It seems the 'unrelated' builds were directly relating the next build. Strange. After I deleted all my previous apps, my app went down to the expected ~112 app size. Packaged, it is 40 (as expected). This seems like a strange bug.

Thanks @paulcbetts

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