Doing a git blame on this line explains it’s needed for the vst3 helper tool: "Ensure bundle is adhoc-signed before attempting to run vst3 or lv2 helpers"
This is causing a problem for us, because our group-wide shared macOS signing action on GitHub Actions would need to use the --force flag when calling codesign to overwrite the adhoc signature. Currently this signing is failing due to "path/to/my-plugin.vst3: is already signed". We really don’t want to have to use --force as that could be problematic for other teams using that shared signing action.
Could we please have an option somewhere to disable this ad-hoc signing?
Assuming the signing is required to run the vst3 helper - could we have an option to not run the helper and so not have the plugin signed either?
If you disable the ad-hoc signing your builds might fail because the VST3 won’t be loaded in some cases, if you skip the manifest generation your plugins will be slower to load in some hosts. Are there any specific problems you are aware of when using the --force argument? I wonder if alternatively you could try running codesign --remove-signature my-plugin.vst3 before passing the bundle to your group wide shared macOS signing action?
Are there some docs somewhere about what the vst3 helper tool does?
The problem is simply that it would overwrite any existing signature, so if someone else using that pipeline accidentally passed in a file to be signed that had already been signed, it would be replaced. E.g. we bundle Sparkle.app in FC2 which is already signed by Sparkle so using --force would replace their signature with ours, which isn’t great. I.e. we want the action to fail if you pass it a file that’s already signed
Yeah so I’ve added this as a POST_BUILD command for the specific project that’s currently failing - but this would mean we’d have to do this for every project in the group that’s building VST3’s with JUCE, both now and in the future.
Could JUCE add that POST_BUILD step as part of its own CMake to remove the adhoc signature after the vst3 helper tool has finished, the manifest is generated, etc.?
No, but it’s not too complicated. The tool runs after the plugin build to generate a file named moduleinfo.json that lives in the VST3 bundle. This file can be read by the DAW to allow it to discover information about the plugin without having to load the plugin binary, which could be a lot slower. For machines with a few hundred plugins installed, this can make a significant difference in startup time.
Could you check the current signature, and only proceed with signing if there’s no existing signature, or if the signature is ad-hoc? I assume none of your dependencies should be shipped with ad-hoc signatures.
Arm macs can only load and run signed code. Removing the ad-hoc signing would not only break the VST3 moduleinfo tool, it would also prevent users from loading and debugging their plugin unless they added their own signing step. This would complicate the development process, especially for new users who have no exposure to certificates and signing.
I’m reluctant to add friction to the common case in order to streamline a less common case. If the issue can be resolved by checking the current signature and force-overriding or stripping that signature, that feels like a better solution than removing the ad-hoc signing completely.
If there’s a way to specifically check for an ad-hoc signature with codesign then yeah that sounds like a sensible solution for us. A quick google says codesign -dvv should say whether it’s ad-hoc or not.
I was thinking the ad-hoc signature would be removed after the vst3 tool had done its job.
This is quite confusing though as it’s only the VST3 that’s signed - the .component we’re also building doesn’t have any signature. If you’re sure it’s definitely best practice for JUCE to add the ad-hoc signature to VST3, should it not do it for all plugin formats, and all apps?
Why can’t the vst3-helper just copy the .dylib and add the ad-hoc signature to the copy? It’s usually a good idea to avoid modifying sources in build steps, and it means the only side-effect of the vst3 helper is generating new files rather than modifying old ones. iirc the moduleinfo.json only contains information available from the plugin factory so you don’t need to worry about instantiating the plugin, right?
I’d misremembered slightly. We sign VST3 and LV2, both of which must be loaded as part of the build process, in all cases. Additionally, we sign all plugin targets when the plugin copy step is enabled, so that plugins can be loaded and tested in DAWs immediately after building. If you don’t have the plugin copy step enabled, then the .component won’t be signed.
We do this for all plugin formats when post-build copying is enabled, because we received feedback that users were unable to debug their plugins in some cases. We haven’t had this feedback about standalone applications, so I don’t think this is needed. That said, we would add this feature if users started to report that they were unable to run/debug their applications.
We could do this. My main concern would be that this might become expensive for large plugins with lots of bundled resources. Also, as mentioned previously, the plugin needs to be signed anyway for debugging when the plugin copy step is enabled, so copying the plugin, signing it, throwing away the copy, and then signing the plugin would be more wasteful than just signing the plugin a single time.
I’m not sure exactly what you mean here. The plugin DLL must be loaded by the VST3 helper program, so the DLL must be signed. I think it’s true that the VST3 helper only needs to instantiate the IPluginFactory and not any other classes, but I’m not sure that this is a useful distinction. The IPluginFactory code is still defined in the DLL, so the DLL still needs to be signed and loaded.
and checking the value of the Signature= line, which should be adhoc for VST3s produced by JUCE CMake. Then enabled the --force flag if the adhoc signature is present.
