HOWTO macOS notarization (plugins, app, pkg installers)

[e-phonic]

So, my findings are the following:
- If you are using an installer, use the method as described by George.
- If you are distributing a .vst / .component without installer, notarize the plugin.
You can do this by creating a zip file containing the plugin.
Then run:

Code: Select all

xcrun altool --notarize-app --primary-bundle-id "com.company.vst.plugin" --username "USERNAME" --password "PASSWORD" --asc-provider "SHORT_PROVIDER_NAME" --file plugin.zip

You will receive the RequestUUID if all goes well.
To check the status of the RequestUUID:

Code: Select all

xcrun altool --notarization-history 0 -u "USERNAME" -p "PASSWORD"

PJ

[Markus Krause]

If i distribute a .vst within a .pkg do i have to notarize both or just the .pkg that contains the .vst ?

[Richard_Synapse]

Just the package should work fine.

Richard

[Markus Krause]

Thank you Richard!

Markus

[discoDSP]

Does that apply to a .app contained on a .pkg too? It will be a real time saver then.

[Markus Krause]

We don't distribute .app withing the pkg. So i did not test it.

From running tests i disovered this:

- the .vst as well as the .component have both to be code-signed. Otherwise the notarisation does fail

- the vst as well as the component should not contain symbolic links. Otherwise the notarisation fails

- do not use hyphens for your passwords when you use the command-line tools and do not copy&paste Unicode text to the bash. Othwise you will get an error message the the password is incorrect. After a couple of tryes with 'incorrect' passwords you will get an error message that your developer account has been disabled

[audiothing]

Does that apply to a .app contained on a .pkg too? It will be a real time saver then.

Yep. From my previous post:

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.

[discoDSP]

Thanks guys, will update the OP ASAP with your valuable info

[stian]

Thanks for providing this info, George! If anybody are signed into multiple teams through the Apple ID, you'll get an error message that your "Apple ID account is attached to other iTunes providers" and that you'll need to specify an -itc_provider. It wasn't clear to me what an ITC provider is, but using the "Team ID" worked for me.

Best,
Stian

[Richard_Synapse]

Today I noticed another problem, after successful notarization.

For a brief period I was unable to open a notarized package. Has anyone else experienced this, and does opening notarized packages require an online connection?

Richard

[Tale]

For a brief period I was unable to open a notarized package. Has anyone else experienced this, and does opening notarized packages require an online connection?

Well, I believe that the package can be verified without an internet connection, but only when you've stapled the package. If it's not stapled, then I think you do need an internet connection.

[BobDog]

Today I noticed another problem, after successful notarization.

For a brief period I was unable to open a notarized package. Has anyone else experienced this, and does opening notarized packages require an online connection?

Richard

You need to staple the pkg for it to work offline.

Whoops missed earlier post!

[BobDog]

I have been doing some tests here with some hosting software, this has been built with the hardened runtime to allow full compliance. Currently testing this on Mojave.

Not one of the VSTs on my system loads in 64 bit, all with code sign errors. 32 bit is fine.

All AUs load fine in both 32 and 64, so there are no codesign checks on AU only on VST.

when calling CFBundleLoadExecutable() to load the VST, for example Buchla Easel:

Code: Select all

Error loading /Library/Audio/Plug-Ins/VST/Buchla Easel V.vst/Contents/MacOS/Buchla Easel V:  dlopen(/Library/Audio/Plug-Ins/VST/Buchla Easel V.vst/Contents/MacOS/Buchla Easel V, 262): no suitable image found.  Did find:
	/Library/Audio/Plug-Ins/VST/Buchla Easel V.vst/Contents/MacOS/Buchla Easel V: code signature in (/Library/Audio/Plug-Ins/VST/Buchla Easel V.vst/Contents/MacOS/Buchla Easel V) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.

Funny that Apple bypass this for audio units!

The same code with non-hardened runtime and no notarisation, just full signing works absolutely fine on Catalina. I think we need to be aware that testing stuff currently on Catalina that Apple are not enforcing the full shitstorm yet!

[adammonroe]

Does anyone know what the deal is with AAX? Signing AU and VST seems trivial, but I can't seem to get AAX to codesign and verify that it's been codesigned, either via x-code or the terminal. Even if I did, I suspect doing the iLok signing on top of that will invalidate the original codesign when it throws the pace_eden bundle in there. Friggin' mess.

[Urs]

Does anyone know what the deal is with AAX? Signing AU and VST seems trivial, but I can't seem to get AAX to codesign and verify that it's been codesigned, either via x-code or the terminal. Even if I did, I suspect doing the iLok signing on top of that will invalidate the original codesign when it throws the pace_eden bundle in there. Friggin' mess.

I found that AAX plug-ins are codesigned automatically using the 5.x Eden SDK. Verifying with codesign seemed to work just fine.