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?
@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.
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.
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.
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. feedback://showreport?report_id=55982
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