Codesigning plug-ins

Audio Plugins
#1

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?
#2

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.

Other experiences?

1 Like
#3

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.

1 Like
#4

updates:

on macOS 10.14, launching a stand-alone plug-in with invalidated signature results in a crash.

On Windows 10, a stand-alone plug-in with invalidated signature runs without issues, not even a warning message :thinking:

#5

10.14.5 :slight_smile: Apple enforcing codesign…

#6

Yes, crashing with a crash report is a little brutal as a user experience, but at least the code doesn’t run

#7

I’m still on Sierra. Does this mean that any plugin that’s not updated to a version with codesign will be useless on Catalina?

#8

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?

#9

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.

1 Like
#10

Are you sure that’s the behaviour? If you add the “Disable Library Validation” entitlement you can still load unsigned plugins can’t you? https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation

#11

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.

#12

Right, but it doesn’t mean that you can’t load unsigned plugins though. I’m fairly sure we can still load unsigned plugins without the app crashing…

#13

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.

#14

From a user perspective: how can one assert if a plugin is signed or not?

#15

My bad. It’s not unsigned plugins that would make Live crash, it’s plugins with an invalid signature (usually cracked).

3 Likes
#16

On macOS, you can use functions of the Security framework. See https://developer.apple.com/documentation/security/code_signing_services?language=objc for more details.

#17

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!

2 Likes
#18

A little utility that I’ve found quite handy in several ways is Suspicious Package

Besides showing what’s contained in a .pkg, it also shows if it’s signed and notarized. Just with a Quicklook tap of the spacebar. Handy.

4 Likes
#19

Great advice. Thanks.