HOWTO macOS notarization (plugins, app, pkg installers)

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

However... I found another possible obstacle:

Code: Select all

$ codesign -dvv path/to/binary
Verifies that the embedded Timestamp is correct. According to here this is only the case if the binary was linked to a base SDK of 10.9+. We always linked to 10.7, so this *failed* and we have to upgrade that. We'll link to 10.9, but use 10.7 as target SDK.

So here's our workflow to upgrade everything for Catalina in the next two months:
  • on an older OS X with XCode 8, we check out (SVN branch) each software at the official release revision
  • in CMake we change the base SDK from 10.7 to 10.9, and in the Xcode project choose 10.7 as target (this links to 10.9, but remains compatible with 10.7 - the build spits out a few warnings, but nothing that really annoys me too much. However, as a precaution, I finally got rid of MoreFilesX :lol: :lol: :lol:)
  • we build 32/64 bit without codesign and keep binaries, info plists and rsrc files
  • we move those files onto a Mojave dev system with Xcode 10
  • there, we take current 64-bit-only builds and replace the binaries/plist/rsrc with these, then run codesign and Eden signing over them
  • we run the package tools with those binaries, codesign the packages and notarise the installer
With this workflow we can create notarised versions of our current official installers without too much hassle, and no need to hastily release updates that involve a lot of testing - our most major concern is releasing untested builds, hence it's a big advantage to release from exactly the code base that the current official installers have. Most of the process (signing, package build etc.) is automated. Branching older revisions and doing clean builds takes some time, but can happen on the side.

Post

Just for the records: we managed to notarize our "old" pkg installer packed with IPLUG1 (WDL-OL) plugins :-)

1) We still use Mavericks to compile, sign and and pack IPLUG1 plugs.
2) Transfer the (unsigned) pkg to Mojave with XCode 10 (later Catalina)
3) => productsign --sign "Developer ID Installer: xxx" "$installername" "$installernamesigned"
4) => xcrun altool --notarize-app -f "$installernamesigned" --primary-bundle-id com.$project_name.pkg --username "xxx" --password "xxx"
5) => xcrun stapler staple "$installernamesigned"

Took us 4 hours to manage this, with help from this forum, thank you! But most of the time we tweaked our firewalls :-) So, seems not really an issue so far...

Post

I ran into a problem with the workflow posted above - one of our plug-ins crashes after codesign & notarisation. Hence, build with Xcode 8, linking to 10.9, transfer to Xcode 10, codesign & notarise may not work in every case. A binary compare shows major additions in the codesigned and stapled binary. Not sure what to make out of this atm...

Post

What you could try is to install an older xcode version on your new Mac. This has solved some compiler and linker issues that i had in the past

Post

Urs wrote: Thu Oct 31, 2019 2:07 pm
adammonroe wrote: Tue Oct 29, 2019 6:14 am 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.
Yes, you are correct! I noticed the last time I signed a plugin with Eden that it also codesigned the plugin. Now I just have to worry about notarization and deployment, which seems to be the major thing here.

Post

Hi, I have a question if I could...

From all the posts here - let me know if I'm wrong - if I have to *JUST* code-sign a single AU or VST or VST3 plugin, I have no need to change the source code of the plugin itself in any way.

Example : imagine I want to code sign a plugin made in 2011. I have no access to its source, but just an access to its "binary" (basically a "folder" on macOS). It's ok to take just that "binary" and use an Apple DEV ID (99USD/year) to codesign it with the :

Code: Select all

codesign -s "Developer ID Application: Your Name" "/path/plugin.component"
codesign -s "Developer ID Application: Your Name" "/path/plugin.vst"
codesign -s "Developer ID Application: Your Name" "/path/plugin.vst3t"
???

If it is ok with this, all previous freeware plugins could be code-signed from a "patron" using his/her Apple DEV ID to code-sign all freewares...
bruno @ Xhun Audio || www.xhun-audio.com || Twitter || Instagram
Image

Post

xhunaudio wrote: Tue Nov 05, 2019 3:17 pm Hi, I have a question if I could...

From all the posts here - let me know if I'm wrong - if I have to *JUST* code-sign a single AU or VST or VST3 plugin, I have no need to change the source code of the plugin itself in any way.
Yes, you can do that, no need to change the source code. Same if you have pkg installers, anyone with an Apple Developer ID could sign/notarize freeware products.

If you don't need to notarize apps/installers, you can just pay Apple for one year only and get a code signing certificate that expires in 5 years. As far as I remember you can renew the certificate one day before the membership ends, essentially giving you 6 years of code signing for $99.
AudioThing (VST, AU, AAX, CLAP Plugins)
Instagram | Twitter | Discord Server

Post

Ohh, thank you AudioThing ,

my biggest concern was that the codesigning process could have an incompatibility with a specific framework (WDL-OL/IPlug1). So it seems not to be the case, thank you for your info !

Yes, I just have to codesign the binaries (I don't use packages). So, if I correctly understood, if I pay 99USD today, I'll get an Apple DEV ID certificate which is valid / usable for the next 5 years. And then, I can renew it FOR FREE for 1 time, before it expires. This free renewal allows you to get 1 more year of Apple dev ID, just for codesigning)... Correct ?
bruno @ Xhun Audio || www.xhun-audio.com || Twitter || Instagram
Image

Post

I don't use WDL-OL/IPlug, I'm using JUCE and I could easily codesign old plugins without recompiling them. If you want, I can test it for you, send me a PM with a link to an old plugin and I'll try later.

Yes, the certificate is valid for 5 years from the moment you create it. I don't know if there are limits on the number of certificates you can create, but as far as I remember, you could create a new one even the day before your membership ends. In my account I have two certificates with different expiration dates (made one month apart).
AudioThing (VST, AU, AAX, CLAP Plugins)
Instagram | Twitter | Discord Server

Post

Thank you ! PM just sent...
bruno @ Xhun Audio || www.xhun-audio.com || Twitter || Instagram
Image

Post

Urs wrote: Sat Nov 02, 2019 8:32 am I ran into a problem with the workflow posted above - one of our plug-ins crashes after codesign & notarisation. Hence, build with Xcode 8, linking to 10.9, transfer to Xcode 10, codesign & notarise may not work in every case. A binary compare shows major additions in the codesigned and stapled binary. Not sure what to make out of this atm...
Scrap that. It was an omission on my side (used wrong UI definition). The workflow works just fine.

Post

Urs wrote: Fri Nov 08, 2019 7:30 am
Urs wrote: Sat Nov 02, 2019 8:32 am I ran into a problem with the workflow posted above - one of our plug-ins crashes after codesign & notarisation. Hence, build with Xcode 8, linking to 10.9, transfer to Xcode 10, codesign & notarise may not work in every case. A binary compare shows major additions in the codesigned and stapled binary. Not sure what to make out of this atm...
Scrap that. It was an omission on my side (used wrong UI definition). The workflow works just fine.
Thank you.
So can we say that there is a high chance to notarize "old"to get such plugins installing and working on Catalina (despite x32)?

Post

TB-ProAudio wrote: Fri Nov 08, 2019 11:04 am
Urs wrote: Fri Nov 08, 2019 7:30 am
Urs wrote: Sat Nov 02, 2019 8:32 am I ran into a problem with the workflow posted above - one of our plug-ins crashes after codesign & notarisation. Hence, build with Xcode 8, linking to 10.9, transfer to Xcode 10, codesign & notarise may not work in every case. A binary compare shows major additions in the codesigned and stapled binary. Not sure what to make out of this atm...
Scrap that. It was an omission on my side (used wrong UI definition). The workflow works just fine.
Thank you.
So can we say that there is a high chance to notarize "old"to get such plugins installing and working on Catalina (despite x32)?
There's a pretty good chance, indeed!

- use XCode 8/9 to build x32/x64 for target 10.7 or newer, link to 10.9 or newer as Base SDK
- use XCode 10+ to codesign for hardened runtime & codesign/notarize Installers

That should do.

Verify code signatures on binaries and installers. Verify notarization on installers. Verify timestamp on binaries. I can't think of anything else right now, I have no idea how to actually check what's gonna happen in January.

Post

Thank you!
Urs wrote: Fri Nov 08, 2019 3:48 pm...I can't think of anything else right now, I have no idea how to actually check what's gonna happen in January.
I'm optimistic: the world will still turn :D

Post

Urs wrote: Thu Oct 31, 2019 2:28 pm [*]we move those files onto a Mojave dev system with Xcode 10
You may be able to do this without a separate machine.

If you download the older Xcode 10.1 from the Apple Dev site, it works with MacOS versions prior to Mojave. You can run it alongside Xcode 8/9, and use it only for notarisation.

I’m able to build, codesign and notarise on the same High Sierra machine, targetting all macOS versions from Snow Leopard to Catalina with the same build.

The only thing I changed from my existing build setup was to add Xcode 10.1 only for its command-line tools, made sure the .pkg contents was also codesigned, and produced a few shell scripts for the notarization and staple commands.
Last edited by Wallander on Sat Nov 09, 2019 9:33 pm, edited 1 time in total.
Arne @ noteperformer.com

Post Reply

Return to “DSP and Plugin Development”