I’m wondering the same thing, I see that they mention “non-app bundles” but then give kernel extensions as an example. We’ve only ever gotten warnings on unsigned apps and installers, but never plugins that run in a (signed) DAW
1 Like
Pure speculation: I guess its okay if the binaries/bundles inside the pkg. But if you have some kind of custom installer (like a self-extracting archive) you have notarise the binaries before and attach it via stapler.
But the final question is, is it even possible to notarise plugins at all or only app-bundles?
Just for anybody who’s interested:
If you manually code sign via “codesign” command you have to add “–options runtime” if you want to harden the runtime
3 Likes
I’m not sure what the output of this thread is. Hope someone can clarify:
- Is it possible and required to notarise the plugins itself?
- Is it possible and required to notarise the installer *.pkg file?
I managed to successfully verify the pkg file and i want to share. My package contains a VST, VST3, AU and AAX. No standalone version.
First i signed the plugins, except for the AAX (this is already signed). I do this inside a XCode post build shell script, but it’s also possible to do this later:
codesign -s "$certificateId" "$HOME/Library/Audio/PlugIns/Components/$PRODUCT_NAME.component"
After that i have created a pkg containing the plugins. I used the script above to notarise and it worked in my case (thanks for sharing):
sh notarize-app.sh $NAME-installer.pkg --primary-bundle-id=id
I’m not sure what to use for the bundle identifier, because it is a package and does not have any. Anyway, i’ve received a status 0 successful 
Any input is welcome.
6 Likes
I just got this working with some tips from @dave96 . In my experience if you’re bundling everything up as a DMG file or pkg file you can just notarise the top level thing and it will notarise the contents. You don’t have to do plug-ins but if you’ve got a standalone app that would have to be codesigned with hardened run time, And then notarised
3 Likes
The bundle ID doesn’t matter according to Apple documentation
2 Likes
I’d still love to understand whether or not code-signing the binaries is a requirement. @olilarkin’s post implies notarizing the top level pkg would be sufficient but: does that fail if the binaries are not code-signed?
Yes, I’m pretty sure they need to be codesigned using the --deep --strict --options=runtime flags.
1 Like
Yeah, I made a mistake there. I was just playing with Apple’s latest AU Host sample code which has hardened runtime enabled, and got some errors because my .component was not code signed. Enabling codesigning in xcode, and re-notarizing fixed it [edit… not so sure, now crashing logic, going to try cmdline]
https://developer.apple.com/documentation/audiotoolbox/incorporating_audio_effects_and_instruments
1 Like
removing any attributes with xattr -cr MyPlugin.component and then codesigning with --deep --strict --options=runtime did the trick
3 Likes
September 3, 2019
As a reminder, Mac software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina. To make this transition easier and to protect users on macOS Catalina who continue to use older versions of software, we’ve adjusted the notarization prerequisites until January 2020.
You can now notarize Mac software that:
- Doesn’t have the Hardened Runtime capability enabled.
- Has components not signed with your Developer ID.
- Doesn’t include a secure timestamp with your code-signing signature.
- Was built with an older SDK.
- Includes the com.apple.security.get-task-allow entitlement with the value set to any variation of true.
Make sure to submit all versions of your software. While Xcode 10 or later is still required to submit, you don’t need to rebuild or re-sign your software before submission.
3 Likes
Does this mean that as of January 2020 it won’t be possible to build against anything other than the Catalina SDK?
If you want to get your software notarised, imho yes!
But I just wonder 
what happens, to discontinued software (even from 2018), if the binaries didn’t get notarised, will they all fail to open on Catalina, unless gatekeeper is bypassed?
I really hope not since OpenGL is totally broken in the latest SDK.
That’s why you stop using it, subtle aren’t they?
Some developers still aren’t even signing their installers, so a right-click open is all that’s needed for those cases and users are quite familiar with doing this to get around it. Will this be the same for things that have not been notarised? Not looking for excuses not to do it, but any concern about being able to use discontinued software is a valid one.
3 Likes
-
Does signing (via codesign command) with “option runtime” actually mean that the signed binary will get a “hardened runtime”, or is that only a part of process which is required to get a “hardened runtime” together along with a Xcode option for hardened runtime?
-
Can a plugin host with a hardened-runtime load plugins which don’t have “hardened runtime” enabled?
As far as I know, hardened runtime is required by applications and not by plugins. We need to do code signing and notarize the installers. What I can see, is that if you already have a certificate issued by Apple, your stuff will run without any more hassles than Mojave. I tried installers made in 2018, without code signing and everything installs and runs fine.
To check if a host supports hardened runtime:
codesign --display --verbose /Applications/<the host>
Sample of a host that does not have hardened runtime (e.g. Studio One 4.5.1):
CodeDirectory v=20200 size=158103 flags=0x0(none) hashes=4935+3 location=embedded
Sample of a host that does have hardened runtime (e.g. Studio One 4.5.4):
CodeDirectory v=20500 size=158819 flags=0x10000(runtime) hashes=4954+5 location=embedded
I tested plug-ins that were not notarised and did not have hardened runtime, they worked on both versions.
I think the only wrinkle in this is that the host and plug-in scanner need to have the com.apple.security.cs.disable-library-validation entitlement to load unsigned code if the plugins are not signed, which I suspect most hosts are quite likely to do.
There are also other flags needed for iLok plug-ins to work correctly, and I suspect most hosts will include those as well once they’ve discussed the requirements with Pace.
1 Like