How to add entitlements to a Xojo app using codesign

I’m now code-signing my app with hardened runtime, and seeing these errors:

Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for ACC:{ID: com.mycompany.myapp, PID[1131], auid: 501, euid: 501, binary path: '/Users/me/Desktop/Remote Debugger/MyApp.debug.app/Contents/MacOS/MyApp.debug'}, REQ:{ID: com.apple.appleeventsd, PID[279], auid: 55, euid: 55, binary path: '/System/Library/CoreServices/appleeventsd'}

The weird things:

  • I did add the plist key
<key>com.apple.security.automation.apple-events</key><true/>

yet I still see the warning.

Also, I don’t think my app actually uses AppleEvents. I had some old AppleEvents code (such as Application.HandleAppleEvent), but I removed it, and am still seeing the warning. I’d rather not use AEs and not have the entitlement at all.

And I have another app which is not triggering the warning.

So there’s probably somtehing in my app that references AppleEvents.

Any ideas where to look?

Edit: typos.

Technically every application uses AppleEvents. oDoc is used when double clicking a file in the Finder. nDoc is used to tell the application to create a new document, IIRC rDoc is used when clicking on the Dock icon.

According to this document “kTCCServiceAppleEvents” is a private API for Apple only apps.
https://www.felix-schwarz.org/blog/2018/06/apple-event-sandboxing-in-macos-mojave

So if you’re using that somewhere in your entitlements; you shouldn’t be.

However looking at the message it not only lists your application as needed the correct entitlement; but also the Apple events Daemon. Which suggests to me that this is a failure on your machine. First thing to try is to restart Windows, macOS.

So I poked around in the plists for Automator and Script Editor, and neither of those apps have any com.apple.security.*** entitlements at all.

Back looking at my app, the one thing I’m suspcious about is that my app defines a FileType for APPL (this app is actually an app builder, and builds applications and installers, so that’s not unreasonable).

I wonder if this could be causing the OS to get confused?

Just to make sure… there are two different plist’s involved:

  • App - Info.plist: Here you put the required “Usage Descriptions”, e.g.: NSAppleEventsUsageDescription
  • Entitlements.plist: not used within the App itself / not part of the App’s “Info.plist”. This one is used as a parameter for codesign, e.g. Apple Events Entitlement
    So having the com.apple.security.automation.apple-events Entitlement just in the App’s “Info.plist” (but not applied with codesign) won’t do anything at all. The “UsageDescription” is needed to tell the user why you want it (don’t have it - app won’t do it). And the codesign-Entitlement is additionally required to “technically allow” it (once the app is codesigned with “hardened runtime”, which is also required when it’s “notarized”). That’s at least my understanding of these two different plist’s.

That still doesn’t explain why AppleEvents/Script seem to be involved in your case when you’re saying that you don’t use them at all…

Right - because that one doesn’t belong there - see my previous reply :wink:

@Michael Diehr — As Jürg stated, you need to create a plist file (usually with the extension “.entitlements”) where you set com.apple.security.automation.apple-events to true.

For codesigning, use

codesign -f --deep --entitlements <entitlements_file_path> -s "<Apple_ID>" <application_path>

This is confusing, because I know that putting some of these values in my plists has changed the app behavior. For example, my app needs to access the Photos library, so in the plist I have:

	<key>NSPhotoLibraryUsageDescription</key>
	<string>MyApp can use images, movies, and metadata such as title and description when you drag &amp; drop items from the Photos app.</string>

	<key>com.apple.security.personal-information.photos-library</key>
	<true/>

And it has been working fine across several OS versions. N.B. this app is NOT sandboxed, if that matters.

But it sounds like I’ve totally been doing it wrong??? Did the rules change?

I wonder if macOS has some “helpful” heuristics that have been making my app work properly even when I wasn’t doing it right?

@Michael Diehr — Maybe that came with the hardened runtime?

The answer is simple but complicated. I’m changing the title of this thread to be more generic.

<key>NSPhotoLibraryUsageDescription</key>
	<string>MyApp can use images, movies, and metadata such as title and description when you drag &amp; drop items from the Photos app.</string>
  • However, the actual key/value pairs for Entitlements instead have to be added during the code-signing process, they do not belong in Info.plist at all
  • To do this, first Create an entitlements plist file (the name doesn’t matter, but I use myapp_entitlements.plist) which looks like this:
<?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>
[... followed by a list of entitlements that you need for your app ... ]
	<key>com.apple.security.assets.pictures.read-write</key>
	<true/>
	<key>com.apple.security.automation.apple-events</key>
	<true/>
	<key>com.apple.security.personal-information.photos-library</key>
	<true/>
[... etc ...]
</dict>
</plist>
codesign --force --options runtime --deep --entitlements /path/to/myapp_entitlements.plist --sign  'Developer ID Application: my company' /path/to/myapp.app
  • to see what entitlements an app has, use this command:
codesign -d --entitlements :- /path/to/myapp.app

@Michael Diehr — Thanks for the summary.

Now you are a pro in codesigning :slight_smile:

Edit: turns out some keys were causing trouble. These keys:

	<key>com.apple.application-identifier</key>
	<string>com.mycompany.myapp</string>

With those in place, I’d get warnings:

 trustd	SecWarning	Entitlement com.apple.application-identifier=com.mycompany.myapp is ignored because of invalid application signature or incorrect provisioning profile

Without, it works fine. Removed them and edited the solution above.

Additional caveat: if your app contains Helper apps, then if you sign the entire master app with the “–deep” option, your entitlements will be applied to the helper apps as well.

In my case, that’s not what I wanted, so I had to alter my signing scripts to sign each part inside-out (sign the helper apps first, then sign the master app’s dylibs, then the app itself, not using the “–deep” option.

Yup, I think you’ve got it all now and can use it as a pro :wink: