Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add option to specify login helper entitlements file #210

Merged
merged 4 commits into from
Jun 11, 2020
Merged

feat: Add option to specify login helper entitlements file #210

merged 4 commits into from
Jun 11, 2020

Conversation

oNaiPs
Copy link
Contributor

@oNaiPs oNaiPs commented Oct 15, 2019

When signing the electron app for App Store, the Login Helper is signed child inherited entitlements. Since the Login Helper is a standalone executable, it crashes on because it shouldn't have the com.apple.security.inherit.

This PR adds an option to specify a custom entitlement file for the login helper.

@greenimpala
Copy link

I can confirm this is an issue if you are trying to get a MAS app to start at login. @oNaiPs the fix you propose works (I am currently applying it with patch-package) for the time being.

electron-osx-sign+0.4.15.patch.zip

I think you have some linting issues (semicolons etc) from looking at the circleci failing build.
Hopefully if those are fixed somebody can merge this :)

@sethlu
Copy link
Contributor

sethlu commented Apr 12, 2020

I'll can get this merged if the checks are passing 😸

Also I think it may be better to default the login helper entitlements to the default.entitlements.mas.plist/default.entitlements.darwin.plist instead of the child entitlements file... since the login helper doesn't launch as a child process so the key com.apple.security.inherit may be unnecessary?

Ref: https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md

@greenimpala
Copy link

@sethlu correct, the login helper should only have the sandbox entitlement to work correctly. If we add inherit (or anything else) - it breaks.

With that in mind, I am wondering whether it is overkill to provide a custom plist for login helper entitlements to fix this. Instead we could just change electron-osx-sign to sign any Library/LoginItems binary with default.entitlements.mas.plist?

@sethlu
Copy link
Contributor

sethlu commented May 4, 2020

@greenimpala I agree that it may be a better approach to default to default.entitlements.mas.plist, and a code signed login helper shouldn't harm apps that are distributed outside the Mac App Store without App Sandbox... right? 🤔

I've pushed some changes to this branch following this approach.

sign.js Outdated
opts['entitlements-inherit'] = filePath
}
if (!opts['entitlements-loginhelper']) {
// Default to App Sandbox enabled
filePath = path.join(__dirname, 'default.entitlements.mas.plist')
Copy link

@greenimpala greenimpala May 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we keep current behavior here and sign non-mas builds with the empty default.entitlements.darwin.inherit.plist? We know this is currently working and I wouldn't like to assume adding sandbox will be harmless.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point 🤔

Since the apps that are not going to be shipped on the Mac App Store can still be sandboxed, we may need to take into consideration too if app sandbox is enabled for the Electron app and then selectively apply sandbox for the login helper by default too?

If users aren't enabling app sandbox on their Electron apps for distribution outside the Mac App Store we can fallback to empty entitlements?

Copy link

@greenimpala greenimpala May 12, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that then up to the user to provide a custom entitlements-loginhelper? If they are sandboxing their app then they must have already passed entitlements or entitlements-inherit and be familiar with the custom plist API.

[Edit] Or at this point sign with opts.entitlements. Which would either be a custom plist or the empty default.entitlements.darwin.plist.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like a good idea 👌
So it'll either be the same entitlements to sign the app bundle or a specifically specified entitlements for the login helper.

@jack-arms
Copy link

Hey @sethlu, if I understand this thread correctly the only change before this is ready to merge is

if (!opts['entitlements-loginhelper']) {
  filePath = opts.entitlements;
  ...
  opts['entitlements-loginhelper'] = filePath
}

Do you know approximately when you can make that change? I'm eager to have launching on startup work for the Mac store, and also pipe this functionality through to electron-builder as well.

jack-arms added a commit to jack-arms/electron-builder that referenced this pull request Jun 1, 2020
Port of changes from electron/osx-sign#210, plus changes to macPackager
@sethlu
Copy link
Contributor

sethlu commented Jun 8, 2020

@greenimpala @jack-arms Sorry about the delay!

I've pushed some changes to delay assigning the default value for opts['entitlements-loginhelper'] and it should now be the same entitlements file as what's used to sign the app bundle without user specification.

If you have some time to give it a try that'll be awesome 🙌
If it looks good we can get it out in a few days 😺

@greenimpala
Copy link

greenimpala commented Jun 8, 2020

@sethlu Tried the branch and the behavior is working as expected:

    1. Without entitlements-loginhelper and entitlements it signed LoginHelper with default.entitlements.mas.inherit.plist. (Breaks MAS).
    1. With entitlements-loginhelper it signed LoginHelper with entitlements-loginhelper. (MAS works!).
    1. Without entitlements-loginhelper it signed LoginHelper with entitlements. (Breaks MAS in my case as I have inherit).

Perhaps one more addition — if platform == mas AND !entitlements-loginhelper — sign with default.entitlements.mas.plist instead. This would fix 1 and 3.

@sethlu
Copy link
Contributor

sethlu commented Jun 8, 2020

@greenimpala can you double check if you're running the latest from this branch?

For MAS the following is the current expected behavior:

  • Without entitlements-loginhelper and entitlements it should sign LoginHelper with the default entitlements file default.entitlements.mas.plist (or a locally modified version when pre-auto-entitlements opted in by default) which doesn't inherit sandbox
  • With entitlements-loginhelper it should sign LoginHelper with what's specified
  • Without entitlements-login but with user-specified entitlements it should sign LoginHelper with entitlements (or a locally modified version when pre-auto-entitlements opted in by default) which doesn't inherit sandbox

I think your last paragraph is similar to what we discussed in #210 (comment)?

@greenimpala
Copy link

Tested again (ef288c3) to double check. I had made a mistake with the your last scenario and can confirm it works as expected.

Without any entitlements it signed with the auto-modified default.entitlements.mas.plist! 🎉

@sethlu
Copy link
Contributor

sethlu commented Jun 11, 2020

@greenimpala great, I’m merging this now! Will publish a new release on npm tomorrow 😀
@oNaiPs thanks for starting on the PR!

@sethlu sethlu changed the title Add option to specify login helper entitlement feat: Add option to specify login helper entitlements file Jun 11, 2020
@sethlu sethlu merged commit 114e817 into electron:master Jun 11, 2020
@sethlu
Copy link
Contributor

sethlu commented Jun 12, 2020

@greenimpala Release 0.4.17 is available now 🚀

@greenimpala
Copy link

Great job @sethlu! 🎉

develar pushed a commit to electron-userland/electron-builder that referenced this pull request Jul 9, 2020
* Initial commit

Port of changes from electron/osx-sign#210, plus changes to macPackager

* Update logic in sign.js
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants