Skip to content

feat: automate identifier entitlements when a provisioning profile is supplied - #443

Merged
erickzhao merged 1 commit into
mainfrom
sam/auto-entitlements-provisioning-profile
Aug 18, 2026
Merged

feat: automate identifier entitlements when a provisioning profile is supplied#443
erickzhao merged 1 commit into
mainfrom
sam/auto-entitlements-provisioning-profile

Conversation

@MarshallOfSound

Copy link
Copy Markdown
Member

preAutoEntitlements only kicks in when the entitlements enable com.apple.security.app-sandbox, so it is effectively MAS-only today. Developer ID apps need the same treatment as soon as they embed a provisioning profile: the profile only grants its restricted entitlements (keychain-access-groups, the com.apple.developer.* family, etc) to code that also carries matching com.apple.application-identifier and com.apple.developer.team-identifier entitlements, and AMFI just ignores the profile otherwise. Right now every non-sandboxed app passing provisioningProfile has to hand-write both of those plus ElectronTeamID in Info.plist, which is exactly the boilerplate this automation exists to remove (we've been carrying this as a patch in the desktop app for a while).

So: run the automation when a profile is supplied as well as when the sandbox is on. On the non-sandboxed path we inject the two identifier entitlements (team id from the profile, same as the sandboxed path does when a profile is present) and skip application-groups, since that is the sandbox half of the automation and a Developer ID app shouldn't grow a group it never asked for. Anything the caller already wrote wins, same as before.

Nothing changes for sandboxed apps (the output is byte for byte what it was, there's a test pinning that) or for Developer ID apps without a profile (still an early return, also pinned). preAutoEntitlements: false still turns the whole thing off. The memo key now includes whether a profile was in play so a later profile-less run on the same app doesn't get handed the profile result.

Checked it end to end by running sign() with codesign and security stubbed out and a fake Developer ID profile against a real Electron.app: on main the app is signed with the caller's entitlements untouched and Info.plist has no ElectronTeamID; with this the app is signed with a generated file that adds com.apple.application-identifier = <profile team>.com.github.Electron and com.apple.developer.team-identifier, no application-groups, and Info.plist picks up the profile's team id.

spec/util-entitlements.spec.ts covers the four combinations plus the memo case, three of which are red on main.

… supplied

A provisioning profile only grants its restricted entitlements to code that
also carries matching com.apple.application-identifier and
com.apple.developer.team-identifier entitlements, but preAutoEntitlements
only ran for sandboxed apps, so a Developer ID app embedding a profile had
to hand-write both (and ElectronTeamID) or the profile did nothing.

Run the automation for non-sandboxed apps too when a profile is supplied,
injecting the two identifiers (team taken from the profile) and leaving
application-groups alone, since that is a sandbox concern. Sandboxed apps
and profile-less Developer ID apps are unchanged.
@MarshallOfSound
MarshallOfSound force-pushed the sam/auto-entitlements-provisioning-profile branch from 0b69f96 to bd97a80 Compare August 10, 2026 21:22
@erickzhao
erickzhao merged commit d03062e into main Aug 18, 2026
7 checks passed
@erickzhao
erickzhao deleted the sam/auto-entitlements-provisioning-profile branch August 18, 2026 20:31
@electron-npm-package-publisher

Copy link
Copy Markdown

🎉 This PR is included in version 2.7.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants