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
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
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.
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
The bundle ID doesn’t matter according to Apple documentation
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.