While experimenting with hardening I noticed that some Xojo plugins are codesigned and some are not codesigned. Before I contact the plugin authors: why should a plugin be signed? Because it’s like an app and everything needs to be signed?
The codesign documentation is a bit vague (Understanding the Code Signature). It just says:
It doesn’t say “plugins need to be signed”. I codesign my app with the plugins. If the plugins are signed then I can trust the plugins more?
From WWDC: A future version of MacOS may decide to only execute signed code, like iOS.
How does this apply to plugins? Do they need to be signed so that Xojo can use them independently if I use the plugins in my app?
Eventually all plugin developers will have to code sign their plugins.
Nothing to worry about.
All plugins that you use in your application have to be codesigned with your certificate; this is Apple’s way of saying that you’re accepting responsibility for the code within the plugins.
Same goes for frameworks and helper applications.
@Christian Schmitz: some plugin authors don’t keep up with news as much as we do. So “nothing to worry” about doesn’t really reassure me. The Valentina folks don’t have a 64bit installer for their plugin.
@Sam Rowlands : yes, I know.
I think what Christian is saying is that Xojo will need codesigned plugins in the future or it won’t be able to load the plugins. This makes sense.
No, the vendor needs to code sign their plugins.
If they don’t, email them to ask them to make sure they code sign.
It will be required eventually.
On the other hand, if the vendor do not sign its plugin, check if hes still alive 
We’ll see how this turns out… I don’t know if the Xojo IDE “executes code” from the Plugins, and if that applies to just “reading/loading” (but not “executing code”), too.
And if they don’t, one can always CodeSign a Plugin with an own certificate Xojo will need their IDE to have Disable Library Validation anyway. So it doesn’t really matter if the Plugins are signed by the Plugin-Developer/Vendor, or by the Xojo-Developer.
@Christian Schmitz: sometimes… I want to write the plugin developers. But I don’t want to write “hey, you should codesign because it’s nicer”.
@Jürg Otter: very good idea.
Technically you should be verifying the signature of every plugin you use before applying your signature anyway, just to be sure that they havent been tampered with since they were built. Thats the whole point of a code signature anyway.
Thanks, Greg!
So I made request again in Feedback to add com.apple.security.cs.disable-library-validation to the Xojo IDE itself to be able to load plugins in future MacOS versions. <https://xojo.com/issue/55982>
Scratching head. If Xojo won’t implement 55982 why would they implement the identical 56139?
They don’t want to include that for ->built applications<-. Because then the Developer needs to decide how to CodeSign (if at all).
But… to allow the XojoIDE to load/run 3rd party Plugins, the XojoIDE.app will need that Entitlement. That’s just because we (or Plugin vendors) can’t codesign them with Xojo’s certificate 
Thanks, Jürg, didn’t read the second sentence of 55982.
It should not be too much of an issue for App Wrapper users. As far as I know, it already code signs each plugin.
I think, only if “Use same identifier for all components” is activated. And in my App Wrapper (3.9 (294)) this option is not even accessible (ghosted).
It does
Thats how it eve loads them into the IDE