HOWTO macOS notarization (plugins, app, pkg installers)

[fuo]

e-phonic reported that plugin require notarization to work: viewtopic.php?p=7549797#p7549797

I uses the same steps as his (you also quoted them in your original post), but the staple part is missing.
From what I understand notarization can still work without the ticket being stapled, but will require the machine to be online in this case. I have a feeling this will generate support issues...

[fuo]

Here is the detail from the error I get when stapling the ticket to Contents/MacOS/XXX :

Code: Select all

Could not remove existing ticket from XXX.vst3/Contents/MacOS/XXX/Contents/CodeResources
(...)
Error Domain=NSCocoaErrorDomain Code=512 "“CodeResources” couldn’t be removed."
(...)
{Error Domain=NSPOSIXErrorDomain Code=20 "Not a directory"}

It looks like it tries to erase a directory that does not exist in a plugin bundle...

[george]

You can find some info about notarizing plugins here:
https://developer.apple.com/documentati ... n_workflow

From that link:

The notary service generates a ticket for the top-level file that you specify, as well as each nested file. For example, if you submit a disk image that contains a signed installer package with an app bundle inside, the notarization service generates tickets for the disk image, installer package, and app bundle.

I only submit the dmg with a pkg installer containing the plugins and I can confirm that the PKG gets notarized as well. If I check the notarization for the plugins with the command

Code: Select all

spctl --assess --verbose 

I get this:

Code: Select all

rejected (the code is valid but does not seem to be an app)

I don't know if there's a specific command to check notarization for plugins, but according to that document, by submitting a pkg or a dmg with a pkg inside, we should be good to go.

Based on this, there no need for plugin notarization at all.

[fuo]

e-phonic experience was that notarization was needed:

AFAIK Plugins are not required/able to be notarized but they have to be digitally signed else they won't load in the DAW.

As far I know, plugins also need to be notarized. I couldn't run my signed plugins after they are downloaded from the internet. After notarization they run fine.

PJ

Are you referring to .app or .component/vst/vst3/aax?

I have the latter signed only and they run fine on Catalina.

It’s a .vst.
When it’s signed it seems to run fine first. But when I upload it and download it again, it will not run anymore. I’ve read somewhere in the documentation that all software needs to be notarized. They specifically mention plugins too.

[audiothing]

Notarization is indeed needed for plugins, but if you are distributing through a PKG or DMG (which contains a PKG), you can just notarize the PKG or the DMG, and everything inside will be notarized.
If you are distributing your plugins with a simple ZIP file, you still need to notarize that (you are actually notarizing the content of the ZIP). The problem here is that you can't staple a ZIP file (as far as I remember). But it worked when I tested it.
That said, distributing with a PKG is the way to go, it's easier for the user, and you can automate the whole process (PKG creation, signing, notarization + stapling) with just a small bash script.

[george]

Notarization is indeed needed for plugins, but if you are distributing through a PKG or DMG (which contains a PKG), you can just notarize the PKG or the DMG, and everything inside will be notarized.
If you are distributing your plugins with a simple ZIP file, you still need to notarize that (you are actually notarizing the content of the ZIP). The problem here is that you can't staple a ZIP file (as far as I remember). But it worked when I tested it.
That said, distributing with a PKG is the way to go, it's easier for the user, and you can automate the whole process (PKG creation, signing, notarization + stapling) with just a small bash script.

Now that it's clear I will place the quote at the OP thanks.

[fuo]

Thanks AudioThing!
I was able to confirm this in my tests.
So the mains drawback is that the user needs to be online when using the plugin for the first time.

I don't know if that is mentioned in the thread, but I also found that removing the AU caches was needed when a unnotarized version of the plugin was previously installed on the machine.

[george]

I also found that removing the AU caches was needed when a unnotarized version of the plugin was previously installed on the machine.

That's new. Thanks for pointing up. Wasn't just killing AudioComponentRegistrar enough?

Code: Select all

sudo killall -9 AudioComponentRegistrar

[fuo]

I did not try that, I did not know about that (I am new to MacOS).
Do you include these steps in your installer?

EDIT: looks like you do indeed: viewtopic.php?t=531117

[Mundox]

So distributing plugins in zip is a no go for the future...

From my experience, .zip files are frowned upon by browsers.
Also, the download plugin I use on my site for example doesn't allow .zip at all.
I've been using .dmg (and .exe for Windows) for distribution and never had issues.

[Lind0n]

Ok just a quick additional note. I was having problems getting my app to codesign, it kept telling me:

unsealed contents present in the bundle root

It turns out it wont get codesigned if you've added an application icon to your app, so the simple process of : click on your app, select GetInfo, click on the default icon, and paste in some other image

At this point your app has a nice friendly image of your choosing - and it WONT codesign - it has to have the default image in place - in my experience.

Not sure if you can add a friendly image after the codesign or after the notarizing...any one have any experience?

[ASJPlugins]

Ok just a quick additional note. I was having problems getting my app to codesign, it kept telling me:

unsealed contents present in the bundle root

It turns out it wont get codesigned if you've added an application icon to your app, so the simple process of : click on your app, select GetInfo, click on the default icon, and paste in some other image

At this point your app has a nice friendly image of your choosing - and it WONT codesign - it has to have the default image in place - in my experience.

Not sure if you can add a friendly image after the codesign or after the notarizing...any one have any experience?

unsealed contents present in the bundle root
I got tripped up when I copied a notarized and stapled package over to a USB drive. macOS wrote hidden files (.DS_Store and ._.DS_Store) into the bundle root, which invalidated the notarization.

[Markus Krause]

Looks like another Notarisation debacle just arrived with Big Sur:

FYI: productsign on Big Sur is broken and not adding SHA1 hashes (only SHA256) so your pkg won't install on anything older than 11.12. Don't upgrade your build machines yet.

Thanks a lot for this important info. I think you mean 'older than 10.12' (typo).
Sounds like another 'planned obsolescence' from Apple's side. Customers are necessitated to buy new machines to be able use the new software

As a result in practise we would have to drop support for anything below 10.12 if we support Silicon

Another point:
Does it affect only signing the .pkg or also the code-signing?
I am not sure if code-signing and package-signing on two different machines works to pass the Notarisation.

And another one:
Are customers below 10.11 still able to install the software signed with Big Sur with "high-click +Open"?

[kv331]

Hi all,

My notarization script has been working fine, but recently Apple is rejecting

I codesign all binaries
I codesign all pkg files

and yet I am not getting errors like below:

"issues": [
{
"severity": "error",
"code": null,
"path": "SynthMasterDemoSetup.pkg/synthmastervstdemo.pkg Contents/Payload/Library/Audio/Plug-Ins/VST/SynthMaster2FX.vst/Contents/MacOS/SynthMaster2FX",
"message": "The signature of the binary is invalid.",
"docUrl": null,
"architecture": "x86_64"
},

[george]

I remember some issues with
VST. Signing the specific file may fix it.