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.
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.
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?
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…
@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.
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 & 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?
examples of other security-related tags which belong in the Info.plist are the human-reable descriptions, such as
<key>NSPhotoLibraryUsageDescription</key>
<string>MyApp can use images, movies, and metadata such as title and description when you drag & 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>
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.