Correctly set the security application group to support correct app sandboxing for MAS on OSX

[MarshallOfSound]

As per a recent change to Electron. When building for MAS this string variable needs to be correctly set. Electron packager should set this string for us 😄

https://github.com/electron/electron/pull/5584/files#diff-2438340ff7dedbdf61d9a8373a7befb3R57

Although this can't be implemented yet as there is not a released version of electron with this new requirement I thought I would open this here to allow for feature/issue tracking

[malept]

I think this would be more suited for electron-osx-sign. Never mind, you have to add something to the plist, huh.

[develar]

@malept electorn-osx-sign only sign app, it seems our mac.js is a right place to add this string.

[sethlu]

@develar @develar hmm, I think it's partially to do with https://github.com/electron-userland/electron-osx-sign. We'll see how the testing goes first I think?
And if that works out nicely, a patch either to create an entitlements file (during packing as an optional output... or be piped to electron-osx-sign) or to have electron-osx-sign recognize the entry in Info.plist and makes one up (during signing) should work.
(electron/osx-sign#41)

[develar]

@sethlu And electron/electron@5d906c0

So... if I understand correctly, electron-packager must require Team ID and add

<plist version="1.0">
<dict>
  ...
  <key>ElectronTeamID</key>
  <string>TEAM_ID</string>
</dict>
</plist>

to Info.plist.

electron-osx-sign must change entitlements according to docs. Right?

[sethlu]

@develar yup, I think if electron-packager allows a team-id-ish param and tweaks the Info.plist according and electron-osx-sign (1) reads the team-id and does the change from a template entitlements file (2) or gets piped a team-id just as electron-packager, it could probably function.

[develar]

@sethlu Thanks, so I will prepare PR here to add teamId option and modifying Info.plist. (@malept will be cool to accept my PR #351 to avoid merge conflicts :(

[mmm117]

@sethlu Sorry, I am confused.. would it work and pass the MAS review if I follow the guide here? https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md

[sethlu]

@mmm117 As I haven't created a new app since earlier this year, I don't think I may do any tests with submission to iTC. Following the guide, the app should be able to pass the MAS review I think; more updates are available from electron/electron#5584.

[slaskis]

We got our app through the review after updating Electron to 1.1.2+ (which has some MAS related patches).

So yeah, those instructions will let you get through the review assuming the app itself passes the apple guidelines.

And until this lovely tool adds some way to inject the team-id into the Info.plist during packaging we use this command after packaging with electron-packager but before signing with electron-osx-sign to update the Info.plist as in the instructions:

{
  ...
  "inject-team-id": "plutil -insert ElectronTeamID -string $npm_package_osxPackaging_signIdentity dist/Example-mas-x64/Example.app/Contents/Info.plist",
  ...
}

[mmm117]

@slaskis Why don't we just edit the "info.plist" file directly? It seems to be simpler.. doesn't it?

[slaskis]

Well for me the process of testing the app sandbox was a bit tedious because it requires the app to be packaged and signed. It was also the first time I ever worked with the mac app sandbox thus it was a bunch of trial and error. So being able to run it in a single command kept me sane. And hopefully it will help someone else.

Of course you can do it manually, but I guess you could say that about the electron-packager too, it's mostly convenience (and reliability to not miss any manual steps).

[mmm117]

@slaskis It can be done in single command? Including all steps here? https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md

Could you share that command? I only know how to package the app in single command, but not the other steps..

[sethlu]

@mmm117 Well, with previous versions (before the team id was introduced) we could, using electron-packager to finish a app. However, for now, I should recommend the following:

# 1. Package the app
electron-packager path/to/my/app.app # [--everything same as before excluding osx-sign]
# 2. Modify the team id (with the following script or manually do it)
plutil -insert ElectronTeamID -string "TEAM_ID" path/to/my.app/Contents/Info.plist
# 3. Also... Create a custom entitlements file for the app as electron-osx-sign hasn't yet supported a template for the feature (and save it at path/to/my/entitlements.plist). Only need to do it once though.
# 4. Then sign the app with...
electron-osx-sign path/to/my/app.app --entitlements path/to/my/entitlements.plist
# 5. If wish to submit to MAS, use the following to create a flat package (nb: electron-osx-flat comes with electron-osx-sign). It should create a package at path/to/my/app.pkg
electron-osx-flat path/to/my/app.app

A sample entitlements file with team id should be like (ref to https://github.com/electron/electron/blob/d6ab81c1da4630e88f8996dc79c3bb3dda264832/docs/tutorial/mac-app-store-submission-guide.md):

<?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>
    <string>TEAM_ID.your.bundle.id</string>
  </dict>
</plist>

[sethlu]

@malept I've just updated electron/osx-sign#44, which follows the requirement from the Electron docs. 😸 After merged, electron-osx-sign will acknowledge the ElectronTeamID within Info.plist and adjust the entitlements file accordingly (generating a temp file). This should leave electron-packager with not too much work other than adding in the plist the extra key only. What do you think?

[mmm117]

@sethlu Thanks. So do I need to create the following entitlement file "child.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>

[sethlu]

@mmm117 No need I think, the child.plist could follow the default file https://github.com/electron-userland/electron-osx-sign/blob/master/default.mas.inherit.entitlements.

[malept]

@sethlu Hmmm. Just so I understand correctly, is the team ID only needed for signing? If so, since you're already using plist to read from Info.plist, perhaps we should add team ID as an option to osx-sign and let electron-osx-sign handle all of it.

[develar]

@malept I want to avoid double write, so, it is better to add this entry in the electron-packager (since it is required in any case).

[malept]

@develar avoiding writing to the plist twice just means you would pass the file pointer.

[sethlu]

@malept I think ElectronTeamID needs to be in Info.plist before calling codesign. So if Info.plist could provide this entry electron-osx-sign could read from it.
I'm thinking that electron-osx-sign could probably react to app bundles with ElectronTeamID the ones which require the additional com.apple.security.application-groups in the entitlements file. Now we're only writing the Info.plist once, from electron-packager. The other temp file created is just for generating a new entitlements plist for codesign (because com.apple.security.application-groups is correspondingly added).
Let me know what you think 😉

[develar]

As @malept said, it is not electron-packager responsibility to implement sign — this logic goes to electron-osx-sign (and param team ID to https://github.com/electron-userland/electron-packager/blob/master/docs/api.md#osx-sign).

In my PR I am going to pass parsed Info.plist to electron-osx-sign (electron-osx-sign will analyze/modify and save it). Anyway, it is better to discuss in the PR ;) I hope, I will find time tomorrow to do it.

[sethlu]

@develar Thanks for clarifying 😸 I was quite confused just now. (This addition to me's something sitting in between packaging and signing honestly.)
If we're doing it this way, we don't necessarily need to have an extra option, unless the user's team id's different from what's on his identity(, but I doubt if this'll ever be possible)... I could parse out the team id from the identity and automate both Info.plist and the entitlements file.

[develar]

I could parse out the team id from the identity and automate both Info.plist and the entitlements file.

Sorry, I haven't yet investigate what is team id is. I am slowpoke. If team id is a part of certificate common name Developer ID Application: Vladimir Krivosheev (X8C9Z9L4HW) — X8C9Z9L4HW, than we should not add new option.

You cannot get team id from the identity in all cases (it can be specified just as "Developer Name"), in this case we can use openssl to extract common name from cert — https://github.com/electron-userland/electron-builder/blob/master/src/codeSign.ts#L117 (as electron-builder does on CI server). Or maybe using some security command.

[sethlu]

@develar yea I agree. It's possible that someone inputs just his/her name. What about introducing a routine check for the identity name? It matches the input against the keychain contents and finds the corresponding item with a full team id.

[sethlu]

Hi @malept @develar, with electron/osx-sign#44 soon merged, the entitlements file and Info.plist could be automated by electron-osx-sign. Two notable changes are that (1) opts['pre-auto-entitlements-app-group'] flags the automation so with earlier version nothing's affected, and (2) opts.version specifics the Electron version; for all >= 1.1.1, opts['pre-auto-entitlements-app-group'] is enabled by default. It's not possible to disable it with some flag after enabling it though.

Then, signing an app may be like:

electron-osx-sign path/to/my.app --version=1.1.1
electron-osx-sign path/to/my.app --version=1.2.0

So far, the two commands above are equivalent to what shows below:

electron-osx-sign path/to/my.app --pre-auto-entitlements-app-group

as version >= 1.1.1 triggers --pre-auto-entitlements-app-group. I'm not sure if this mechanism may be slightly confusing to beginners... What do you think? The opts are still very flexible/open to changes.

Add:

It's still fine to use:

electron-osx-sign path/to/my.app

... Just the user needs to prepare the correct entitlements file with com.apple.security.application-groups and the item ElectronTeamID in Info.plist.

[malept]

👍 for more automation. How much do beginners actually need to know about the signing process?

[sethlu]

So I think to sign everything by default, electron-osx-sign path/to/my.app should work.

However, with Electron version v1.1.1, electron-osx-sign path/to/my.app --version=1.1.1 should work. And with v1.2.0, electron-osx-sign path/to/my.app --version=1.2.0 works.

However, going to more customizations, someone may have already added ElectronTeamID following the Electron docs, --pre-auto-entitlements-app-group will recognize the setting and will not update the Info.plist. Also, if com.apple.security.application-groups is already declared in the entitlements, --pre-auto-entitlements-app-group will not affect the setting in entitlements.

The only time that someone needs looking at Apple docs is when adding their entitlements keys, but not necessarily com.apple.security.application-groups because it is taken care of by the automation process. Those like com.apple.security.network.client should be added manually and with path to entitlements file specified to electron-osx-sign (like what happens with all previous versions).

Just to clarify: --pre-auto-entitlements-app-group will use either the default entitlements or the user input entitlements as the base to apply any new changes.

So literally all someone needs to know, when signing with the automation introduced, is the version of Electron used (which is put to electron-packager) and the path to the application bundle. Some cases custom entitlements file needs extra work.

--pre-auto-entitlements-app-group only lessens some work with changing Info.plist every time after packaging and inserting the correct entitlements for com.apple.security.application-groups.

[sethlu]

Oh @malept I just thought that it may be better to assume the user's handling the latest version of Electron... So for every version >= v1.1.1, it's fine to use electron-osx-sign path/to/my.app However, for versions earlier electron-osx-sign path/to/my.app --version=0.36.8 for example handles those cases.
Also, if --pre-auto-entitlements-app-group is slightly too much work, I am thinking about reducing this option so all cases are handled with version. Or it's quite troublesome to think about that much.

[malept]

@sethlu I like the idea that electron-packager sends the Electron version that it's going to package and electron-osx-sign will "just work". If you can make that work without too much effort on your end, that would be excellent.

[sethlu]

@malept I've now trying to have opts.version only, however, turning opts.pre-auto-entitlements-app-group to opts.no-pre-auto-entitlements-app-group so automation could be disabled if enabled for specific version by default. The logic's slightly better to follow this way I think.

[sethlu]

@malept Just updated the logic... So it goes like this now:

Use the following for the latest version of Electron:

electron-osx-sign path/to/my.app

However, use the following for better compatibility with earlier versions:

electron-osx-sign path/to/my.app --version=1.1.1 # for example

It's nothing wrong to specify the additional version because it's just there for convenience.

Now if someone wants to use the latest release of Electron, and, however, doesn't walk the full features provided by electron-osx-sign for signing... These include the entitlements automation; the following command is used:

# EITHER
electron-osx-sign path/to/my.app --no-pre-auto-entitlements
# OR
electron-osx-sign path/to/my.app --pre-auto-entitlements=false

So the pre-auto-entitlements acts like a feature which may be disabled for specific Electron versions. And with the debug log displayed, it's quite clear to know if any features are turned on by default:

  electron-osx-sign Pre-sign operation enabled for entitlements automation with versions >= `1.1.1`; disable by setting `pre-auto-entitlements` to `false`. +484ms
  electron-osx-sign Automating entitlement app group... +0ms
  electron-osx-sign `ElectronTeamID` found in `Info.plist`: XXXXXXXXXX +16ms
  electron-osx-sign:warn `com.apple.security.application-groups` not found in entitlements file, new inserted: XXXXXXXXXX.com.electron +1ms

What do you think? This should help slightly with understanding the introduced feat here in a next release. And it's quite easy to set up as the command electron-osx-sign path/to/my.app doesn't change though having a bump.

[develar]

@sethlu I like your solution.

• In the electron-builder we sign app on our side (because code signing on CI server is supported) (i.e. don't use electron-packager to sign).
• electron-buildernow automatically finds appropriate certificate without any configuration and identity name passed to electron-osx-sign is always qualified (i.e. with team id) (on CI server we use openssl to extract common name) . So, logic "find team id" is not relevant for us.

So, in the end, nothing is required to do on electron-builder/electron-packager side, right ;) (except that we should now pass electron version)?

[sethlu]

@develar great! And yes, there's nothing pending for updates on electron-packager and electron-builder... The operations on Info.plist and entitlements file are here on electron-osx-sign. 😸

[malept]

Pretty sure this is handled by electron-osx-sign.