PNS export - unidentified developer

[Dewdman42]

I tried to export a simple PNS script to VST form (MacOS). This VST loaded up into my Cubase 12 here just fine. When I sent it to a friend, the plugins don't appear in their Cubase/Nuendo list of plugins. In another host, VePro, it appears but greyed out with the message "Unidentified developer".

I tried to make sure to use what I thought might be a unique plugin id and manufacturer id...as well as generated a GUID.

Is there something else that needs to be done to make this code signed or something? We are both using latest version of MacOS Monterey 12.4

[Blue Cat Audio]

This has actually nothing to do with the developers IDs. It is a new "security" measure in the most recent versions of MacOS that requires that you codesign all your binaries with a valid Apple developer id.

if you do not want or cannot sign the binaries, it is also possible to remove the quarantine attribute on the downloaded plug-in with the following command line:

Code: Select all

sudo xattr -rd com.apple.quarantine /path/to/yourplugin.vst

[Dewdman42]

hmm interesting. I also got a message in LogicPro while validating the plugin, it complained about the pluginID and manufacturer ID not having at least one capital letter. I changed those id's in export and that eliminated the problem in LogicPro, but the friend that was trying to use it reports that they did also change something in their privacy settings to get around that.

Is it possible for us to code sign these exports in some way so that they don't have to do that step?

[Blue Cat Audio]

Sure, you just have to register as an Apple developer, then get your codesigning certificate from Apple. Once you have it, you can sign the binaries with the codesign utility with your certificate (with the timestamp option or the binary will not be valid for MacOS).

Apple is definitely making it easier to distribute apps and plug-ins these days...

[Dewdman42]

thanks!

[Dewdman42]

What are your thoughts about LogicPro requiring at least one capital letter in the manufacturer and Plugin ID values? Perhaps PNS should enforce that while exporting? Finding a unique plugin and manufacturer id to use is yet a seperate challenge.

[Dewdman42]

$99/year though to be apple developer, which I don't really want to be, nor do I need it enough to pay for that. IS there no other way to code sign stuff on MacOS now...you have to pay $99/year to avoid that problem?

[MirkoVanHauten]

Don't think so. That was one of the complaints and talking points when Apple introduced a problem while selling the solution

[Dewdman42]

The fact that MacOS blocks so many things without being codesigned, is ridiculous then. If you are just making open source type solutions who wants to pay $99? not me. Bleh. Thanks.

[Blue Cat Audio]

Yeah, that's definitely a problem. I wish they had a free solution for free software. I don't think there is any trick to overcome that limitation, as they will check that the certificate has been issued by Apple... I don't know why there has been no lawsuit about this yet...

[Dewdman42]

filing a lawsuit costs more than $99 I guess

[Blue Cat Audio]

Indeed. I meant from the EU or any anti-trust organization.

[ajl1606]

Following on from this, I've experienced trouble getting plugins to run on other people's Macs. Does anyone know the exact process for codesigning and notarising Mac plugins created with PnS?

Currently, I use my Developer ID Application with the --timestamp option when building the .bin file. Then, I export it as an AU file with PnS. That AU file triggers a security warning unless I also forcibly codesign the whole component file (e.g. "codesign -s "Developer ID Application" --force --deep"), but that requires me to do an "xattr -cr ." first on the whole folder. At this point, it now runs on my own Mac, but not on other people's Macs. So, I tried uploading a zip of the plugin to Apple's notarising service using "xcrun notarytool" etc. and, while it says 'accepted' by Apple, the plugin still doesn't open on other people's Macs without the security error.

If anyone's managed to codesign and/or notarise their PnS plugins for Apple successfully, please let me know your process!

Many thanks

[Blue Cat Audio]

Following on from this, I've experienced trouble getting plugins to run on other people's Macs. Does anyone know the exact process for codesigning and notarising Mac plugins created with PnS?

Currently, I use my Developer ID Application with the --timestamp option when building the .bin file. Then, I export it as an AU file with PnS. That AU file triggers a security warning unless I also forcibly codesign the whole component file (e.g. "codesign -s "Developer ID Application" --force --deep"), but that requires me to do an "xattr -cr ." first on the whole folder. At this point, it now runs on my own Mac, but not on other people's Macs. So, I tried uploading a zip of the plugin to Apple's notarising service using "xcrun notarytool" etc. and, while it says 'accepted' by Apple, the plugin still doesn't open on other people's Macs without the security error.

If anyone's managed to codesign and/or notarise their PnS plugins for Apple successfully, please let me know your process!

Many thanks

As far as I know, notarization is actually only required for apps, and does not truly works for plug-ins. Code signing with appropriate timestamp should do the trick, but beware that the code signature might be destroyed depending on how you copy the files. So you may want to make sure it is distributed inside a disk image (or maybe a zip file). If you can create an installer for the plug-in and notarize it, that's even better. No problems for us with that so far.

[ilyaorlov]

I think you should not make .zip, but rather .dmg or installer file, those can only be properly notarized (if I'm correct). After sucessful .dmg notarization I also do "staple", like this:
xcrun stapler staple -q "${DMG_FULL_PATH}"