A little off-topic but interesting.
Do you code sign your plug-ins (excluding PACE/AAX)?
What I know: Mac:
Developers gets codesign as part of their Apple Developer program.
Windows:
Respected sign must be issued from formal CA.
Linux I have no clue.
Dynamic Libs: Code sign can be validated only by the host (since it’s not a real executable)
Currently only Pro Tools AAX utilize codesign integrated with PACE solution.
Do you see any benefit of code-signing plug-ins?
Do you only sign your installers?
If you have a Authenticode compatible code-sign from a CA. do you use it while signing you AAX plugin? is it worth switching to such sign?
I feel this question grew in relevance now that Notarization on macOS requires all code to be signed, including plug-ins.
As a consequence, I have recently started code-signing all plug-in formats on macOS and I’m interested in knowing what hosts are currently requiring the code signature to be valid if present.
REAPER doesn’t seem to care, it loaded without problems plug-ins that were signed and then tampered with, rendering the signature invalid. That happened for all formats supported by REAPER (AU, VST2, VST3)
I’ve also tested with Logic Pro X and it appears that the invalidated plug-in crashes when being validated by auval.
Unsigned plugins can crash Live 10.1.2 and Live 10.1.3. Live 10.1.4 and later shouldn’t crash, but show a dialog (and not load the plugin).
See https://help.ableton.com/hc/en-us/articles/360010030639 for a bit more details.
Not sure I understood what scenario you are referring to.
My tests regard only the following case:
signed plug-in (or stand-alone app), whose signature has been invalidated by changing some bytes in the signed binary (e.g. replacing a character in a string literal)
The case of plug-ins that are entirely unsigned has been mentioned by @McMartin above, but it sounds strange that it causes crashes, perhaps he was referring to the case of invalidated plug-in signature as well?
Live 10.1.2+ is built with hardened runtime. This means that all the code it executes must be signed. If it loads a plugin that is not signed, it crashes.
Live 10.1.4 added a check to test whether the plugin is signed before loading it, to avoid executing unsigned code.
Typically, the Hardened Runtime’s library validation prevents an app from loading frameworks, plug-ins, or libraries unless they’re either signed by Apple or signed with the same team ID as the app.
So that entitlement is needed even for signed plugins.
If the ‘com.apple.security.cs.allow-unsigned-executable-memoryentitlement’ entitlement is set unsigned plugins can be loaded by an app with hardened runtime. Otherwise not. I would be surprised if any hardened hosts didn’t include it otherwise backwards compatibility with older plugins would suffer unnecessarily.
We’re sort of tantalisingly close to a system that would actually get in the way of piracy, since Apple can revoke certificates that any pirates could use to re-sign cracked plugins or hosts.
I’m under no illusion that we are any closer in reality to something that would make a difference at the OS level though!