Moduleinfo.json and macOS notarization

Hi Arne,

I noticed the VST3 SDK uses a command to perform local signing of the moduleinfo.json in SMTG_AddVST3Library.cmake:

 if(SMTG_MAC)
        add_custom_command(
            TARGET ${target} POST_BUILD
            COMMAND 
                codesign -f -s "-" -v "${PLUGIN_PACKAGE_PATH}/${SMTG_MODULEINFO_PATH_INSIDE_BUNDLE}"
                WORKING_DIRECTORY "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}"
        )
endif()

Without this XCode fails to create the bundle and complains that ‘code object is not signed at all’.

Unfortunately, when making an installer for distribution, even after signing everything with a proper Apple developer certificate,
and despite codesign saying the bundle is properly signed, I cannot get it to pass notarization checks using notarytool.
The log states ‘The signature of the binary is invalid’.
If I remove the .json or move it to Resources everything works perfectly.

Are you sure that putting non-code objects at the root of the Contents bundle folder is actually allowed ? According to Apple it strongly looks like it isn’t …
https://developer.apple.com/forums/thread/128166

https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle?language=objc

I suppose you’re using the moduleinfo.json for Steinberg plugins, if so, could you tell us how you solved the issue ?

Thanks,
Lorcan

I will have to talk to some people here. May take some time.

Thanks.
In the meantime I will use the IPluginCompatibility option instead.

For the record this compatibility feature is used by NI Maschine to provide NKS integration for plugins on Apple Silicon where VST2 isn’t available anymore.

Hi Lorcan,
I just checked here to notarize a plug-in installer which includes a plug-in with a moduleinfo.json file and it was successfully notarized by Apple.
Did you really sign the moduleinfo.json with the correct identity? I see that the signing of this file in the SDK is currently broken for release mode as it always signs the moduleinfo.json with an ad-hoc signature.

Yes I did sign the moduleinfo.json with my Apple Developer Certificate, otherwise codesign reports the signature as invalid (the vst3 binary and json signatures don’t match).
Codesign then reports the bundle signature as correct but notarytool disagrees, you get an error in the subsequent log …

What did you notarize? You cannot notarize a .vst3 bundle you need to notarize a pkg installer, zip or disk image.

Yes I notarize the .pkg, prior to that I notarize the .vst3 binary as this is recommended by all sorts of sources including Apple, juce, kvr etc.
Steinberg’s own Halion Sonic SE and Groove Agent SE are also signed and notarized.

And by the way you can notarize a bundle

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow?language=objc

Oh, seems I’m wrong. Sorry. My only contact with notarization was always with pkg.
Which App is the screenshot from?

No problem, signing and notarization is a minefield and Apple keep changing their policies so it isn’t easy to follow.

The app is Apparency.
They also have SuspiciousPackage which is great for installers.

Thanks, if I look at the installed plug-in where I added the moduleinfo.json file, the app Apparency shows the plug-in as notarized.
So if you notarize only the installer the plug-in gets this status after installation. At least this works.

Ok but so you only signed moduleinfo.json with a valid certificate prior to building the .pkg and submitting it to notarization then ?

I’m afraid this won’t work for people not using .pkg installers though, e.g. companies who have center type apps (Plugin alliance etc)

For a deeper analysis I need more time. We have a CI infrastructure that does all the building, signing and notarization for us. So I need to do this by hand to see what happens exactly. For me it doesn’t make sense to disallow notarization in this case, but we will see.