[macOS 10.15] Loading un-notarized plugin bundles fails without hardened runtime enabled

Our application can load third-party plugins, which are created as bundles with the .xop extension, if those .xop bundles are placed in a specific directory.


I have created a signed and notarized version of the main application (MyApp.app) which loads the plugins. When I place a signed and notarized .xop bundle within the correct directory and start my application, the plugin bundle is successfully loaded and I don't get any error messages.


If I place a non-code signed and non-notarized bundle in the same directory and start my application, the OS gives a warning that the plugin "cannot be opened because its integrity cannot be verified."


This happens both when the main application has hardened runtime enabled (with appropriate entitlements) and when it is not enabled at all.


Hardened runtime enabled (with entitlements):

% codesign -dv --entitlements :- MyApp.app 
Executable=[path]/MyApp.app/Contents/MacOS/MyApp
Identifier=[redacted]
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1344903 flags=0x10000(runtime) hashes=42019+5 location=embedded
Signature size=9016
Timestamp=Sep 5, 2019 at 12:14:16 AM
Info.plist entries=23
TeamIdentifier=[redacted]
Runtime Version=10.13.0
Sealed Resources version=2 rules=13 files=48
Internal requirements count=1 size=188
<?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.cs.allow-unsigned-executable-memory</key><true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key><true/>
<key>com.apple.security.cs.disable-library-validation</key><true/>
<key>com.apple.security.cs.disable-executable-page-protection</key><true/>
<key>com.apple.security.get-task-allow</key><true/>
<key>com.apple.security.device.audio-input</key><true/>
<key>com.apple.security.device.camera</key><true/>
<key>com.apple.security.automation.apple-events</key><true/>
</dict>
</plist>



Hardened runtime disabled:

% codesign -dv --entitlements :- MyApp.app 
Executable=[path]MyApp.app/Contents/MacOS/MyApp
Identifier=[redacted]
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=1344795 flags=0x0(none) hashes=42019+3 location=embedded
Signature size=9015
Timestamp=Sep 6, 2019 at 9:39:08 AM
Info.plist entries=23
TeamIdentifier=[redacted]
Sealed Resources version=2 rules=13 files=48
Internal requirements count=1 size=188

Our application is loading the bundle by calling CFBundleLoadExecutable.


Can anyone explain why calling CFBundleLoadExecutable requires that the target bundle be signed and notarized even when the application making the call does not have hardened runtime enabled. Should we be loading the bundle using a call other than CFBundleLoadExecutable?


Thanks

Replies

I forgot to mention that I'm testing on Catalina beta 7.

Can anyone explain why calling

CFBundleLoadExecutable
requires that the target bundle be signed and notarized even when the application making the call does not have hardened runtime enabled.

macOS 10.15 beta has stricter notarisation requirements than previous systems. These apply across the entire system, and thus disabling the hardened runtime on your host app does not change things. I recommend that you watch WWDC 2019 Session 701 Advances in macOS Security, and specially the part leading up to slide 39.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I guess you're referring to this (from the transcript):

"And the first launch policy will be slightly different, where we won't be requiring first launch user approval for standalone executables or libraries, but all bundled software will show first launch prompt."


That seems like a rather arbitrary distinction between a plugin loaded from a bundle vs. from a ***** file, but if this is how things are supposed to work this saves me from filing a bug report. Thanks.

I've been reading the back and forth between RGB255 and Quinn and am grateful for what I've learned from the discussion about plugins. Thank you both.


Quinn, I know you're not the one to gripe to, but my question to you is this: to whom _should_ I send the message below?


The security restrictions imposed by Catalina on non-notarized plugins is going to be a nightmare for a massive swath of the creative users that rely on audio and video plugins to do their creative work. There are many amazing legacy plugins -- created by indie developers or as open source projects -- that are incredibly useful, but are never going to get notarized because those the people who have created them moved on for one reason or another. While I champion safety and security, the fact that there is no way to opt-out of these restrictions at one's own risk is incredibly discouraging. Thousands upon thousands of users rely on extending our software's capabilites through plugins. We need a way to allow that to happen so we can continue to benefit from plugins that we've used for years.


Literally thousands of loyal Apple users are going to be negatively affected by this. We should at least know where we can make our voice heard.


Sincerely,

Mark


P.S. Off topic, but Quinn, it's so awesome that you're still here helping Apple Developers. Every "Letter from the Ice Flow" was a gem that helped me make my software better. Thank you for your continued service to us all. ;-)