Allow to load unsigned/unnotarized plugins on macOS

[Spacechild1]

Motivation

By default, a notarized macOS app will only load plugins that are code-signed. Code signing is a real PITA because it requires an Apple Developer ID (100$ / year). It is a real burden for developers who only want to build for macOS but don't really use the platform.

Pure Data circumvents this problem by setting the com.apple.security.cs.disable-library-validation key to true in the app entitlements: https://github.com/pure-data/pure-data/blob/master/mac/stuff/pd.entitlements

This effectively allows a notarized app to load plugins that are not code-signed. See https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation.

Now, you might argue that this is bad for security. But then consider that macOS is currently the only platform that requires this and I don't think people ever had a problem with malware disguised as SuperCollider extensions in the last 20 years...

Description of Proposed Feature

Set com.apple.security.cs.disable-library-validation to true in SuperCollider's entitlements.

(Does SuperCollider actually have a .entitlements file? I couldn't find any in the source tree...)

Plan for Implementation

[dyfer]

The release version of SC (checked on 3.13.0) does have this key set. Have you encountered a situation where it was not?

Signing SC is currently done manually when doing the release. The process is described here: https://github.com/supercollider/supercollider/wiki/macOS-Signing-and-Notarization

The entitlement file should probably be part of the repo though :)

[Spacechild1]

The release version of SC (checked on 3.13.0) does have this key set. Have you encountered a situation where it was not?

Ah, great, I didn't know that! I just kept getting requests from people who want a notarized binary of VSTPlugin. Now I can tell them to simply upgrade to SC 3.13 :) Thanks a lot!

[Spacechild1]

The entitlement file should probably be part of the repo though :)

+1

[dyfer]

I think the entitlement flag was part of most recent SC releases. However there still may be some issue with loading unsigned plugins; I can't remember if every plugin needed to be confirmed manually, or if they wouldn't load at all. We encountered that when doing the sc3-plugins release (when we couldn't figure out signing for the plugins).

[Spacechild1]

I think the entitlement flag was part of most recent SC releases.

Interesting. Last autumn I had to help students to manually set all the security exceptions to get VSTPlugin running. They all installed the most recent SuperCollider version back then, which must have been 3.12.1. However, last time I tested on a MacBook (macOS 13 Ventura) I didn't have these problems. I now checked the entitlements of SC 3.12.2 and SC 3.13 and they both set the necessary keys, so I am a bit confused...

In general, is SC supposed to load extensions without requiring any sort of manual confirmation or other interference by the user?

[Spacechild1]

Ahhh... I just found this:

Apple silicon requires that all code be at least ad hoc signed.

https://developer.apple.com/forums/thread/694873

IIRC, all the students who had this problems had M1 MacBooks... So I definitely need to code sign sigh. (Ad-hoc code signing should be trivial to do in my CI pipeline, though.)

[dyfer]

Ah yes, sorry, should've mentioned that - binaries don't run at all without signature on apple silicon.

[Spacechild1]

No worries! At least now I understand what's going on :)

[dyfer]

Here's some more info for reference, from my experiences with that:

• unsigned binaries can still be loaded (with warnings etc) on Intel, even in the newest OS I think; on Arm that's blocked closer to the hardware
• when building with the Xcode generator, binaries should be ad-hoc signed automatically
• however, any manipulations like changing loader paths etc invalidates the signature
• in SC we're running ad-hoc code signing explicitly after assembling the package (since we do fixup some paths afterwards, so signing with macdeployqt wouldn't be enough)

[Spacechild1]

Thanks, that's very helpful!

[Spacechild1]

This user claims that they had to explicitly authorize my plugin binaries with SC 3.13 on macOS 13.6.3 (Intel): https://scsynth.org/t/vstplugin-v0-5-4-released/5380/54?u=spacechild1 I'm wondering what's going on...

[Spacechild1]

There are two more users who cannot load VSTPlugin.scx without circumventing the GateKeeper:

The files are signed with IEM's Apple ID, but not notarized. However, the SC app should have the necessary entitlements to load unnotarized plugins.

Strangely, on my Intel MacBook (macOS 13.1) I can open it just fine. Both users have Apple Silicon MacBooks, so that might be a hint...

Can anyone confirm that they can successfully load unnotarized extensions in SC on macOS (Intel or Apple Silicon) without security warnings?

[muellmusik]

I believe the restrictions for Apple silicon are more stringent and require notarising. I had this issue with some custom ambisonic decoders and notarising solved it IIRC.On 5 Jan 2024, at 22:32, Christof Ressi ***@***.***> wrote: There is another user who cannot load VSTPlugin.scx without circumventing the GateKeeper: scsynth.png (view on web) The files are signed with IEM's Apple ID, but not notarized. However, the SC app should have the necessary entitlements to load unnotarized plugins. Strangely, on my Intel MacBook (macOS 13.1) I can open it just fine. Both users have Apple Silicon MacBooks, so that might be a hint... Can anyone confirm that they can successfully load unnotarized extensions in SC on macOS (Intel or Apple Silicon) without security warnings? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Spacechild1]

I believe the restrictions for Apple silicon are more stringent and require notarising.

That's what I figured as well. Sadly, I cannot find any official documentation about this, which is rather frustrating...

[joshpar]

So - there is a way, from the command line, to unquarantine files, and that might work In a Terminal, I think if you run this on the scx file xattr theplugin.scx You will see: com.apple.quarantine Then, you can run xattr -d com.apple.quarantine theplugin.scx To remove the quarantine You may have to do this as sudo Hope that helps! Josh

…

On Jan 5, 2024, at 12:38 PM, Christof Ressi ***@***.***> wrote: I believe the restrictions for Apple silicon are more stringent and require notarising. That's what I figured as well. Sadly, I cannot find any official documentation about this, which is rather frustrating... — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[muellmusik]

IIRC that doesn’t work on AS. Better to just notarise the binaries.On 6 Jan 2024, at 09:09, Joshua Parmenter ***@***.***> wrote: So - there is a way, from the command line, to unquarantine files, and that might work In a Terminal, I think if you run this on the scx file xattr theplugin.scx You will see: com.apple.quarantine Then, you can run xattr -d com.apple.quarantine theplugin.scx To remove the quarantine You may have to do this as sudo Hope that helps! Josh

On Jan 5, 2024, at 12:38 PM, Christof Ressi ***@***.***> wrote: I believe the restrictions for Apple silicon are more stringent and require notarising. That's what I figured as well. Sadly, I cannot find any official documentation about this, which is rather frustrating... — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[muellmusik]

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distributionOn 6 Jan 2024, at 09:20, Scott Wilson ***@***.***> wrote:IIRC that doesn’t work on AS. Better to just notarise the binaries.On 6 Jan 2024, at 09:09, Joshua Parmenter ***@***.***> wrote: So - there is a way, from the command line, to unquarantine files, and that might work In a Terminal, I think if you run this on the scx file xattr theplugin.scx You will see: com.apple.quarantine Then, you can run xattr -d com.apple.quarantine theplugin.scx To remove the quarantine You may have to do this as sudo Hope that helps! Josh

On Jan 5, 2024, at 12:38 PM, Christof Ressi ***@***.***> wrote: I believe the restrictions for Apple silicon are more stringent and require notarising. That's what I figured as well. Sadly, I cannot find any official documentation about this, which is rather frustrating... — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[joshpar]

I have put notes for this up on the wiki as well. https://github.com/supercollider/supercollider/wiki/macOS-Signing-and-Notarization macOS signing and notarization github.com

…

On Jan 5, 2024, at 6:22 PM, Scott Wilson ***@***.***> wrote: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distributionOn 6 Jan 2024, at 09:20, Scott Wilson ***@***.***> wrote:IIRC that doesn’t work on AS. Better to just notarise the binaries.On 6 Jan 2024, at 09:09, Joshua Parmenter ***@***.***> wrote: So - there is a way, from the command line, to unquarantine files, and that might work In a Terminal, I think if you run this on the scx file xattr theplugin.scx You will see: com.apple.quarantine Then, you can run xattr -d com.apple.quarantine theplugin.scx To remove the quarantine You may have to do this as sudo Hope that helps! Josh > On Jan 5, 2024, at 12:38 PM, Christof Ressi ***@***.***> wrote: > > > I believe the restrictions for Apple silicon are more stringent and require notarising. > That's what I figured as well. Sadly, I cannot find any official documentation about this, which is rather frustrating... > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#6132 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANHLEZ2PBYRJWW5OUCGADYNCYM5AVCNFSM6AAAAAA7F5MWT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGUYDCNZUG4>. You are receiving this because you commented.

[Spacechild1]

@joshpar Yes, there are ways to manually unquarantine the plugin. It is also documented in the README: https://git.iem.at/pd/vstplugin#macos-1015

@muellmusik This does work on Apple Silicon, btw!

However, I would rather like if users wouldn't need to do this. On the other hand, I don't think it is reasonable to require open source developers to purchase an Apple Developer ID and notarize their plugins.

I have put notes for this up on the wiki as well.

@joshpar The wiki only shows how to codesign plugins, but not how to notarize them. https://github.com/supercollider/supercollider/wiki/macOS-Signing-and-Notarization#signing-and-notarizing-a-single-plugin-file

Generally, I would like to see some definite proof that plugin notarization is mandatory on Apple Silicon. This would actually mean that the disable-library-validation entitlement would be meaningless. I haven't read anything in this regard in the official documentation...

[Spacechild1]

I just have one suspicion: scsynth runs as a subprocess. While the docs say that entitlements are inherited by dylibs, frameworks and plugins, it does not say anything about subprocesses:

You add entitlements only to executables. Shared libraries, frameworks, and in-process plug-ins inherit the entitlements of their host executable.

https://developer.apple.com/documentation/security/hardened_runtime

[Spacechild1]

@joshpar Some short unrelated question: in https://github.com/supercollider/supercollider/wiki/macOS-signing-and-notarization#signing-and-notarizing-a-single-plugin-file you are also setting entitlements. Is this really necessary? The Apple docs above say that this is only needed for executables, not for plugins.

[muellmusik]

I completely agree, though it seems unavoidable. Are you still at IEM? Maybe they will foot the bill? I ended up doing this here at Brum though it was a major pain with an institutional working group, largely because they had no knowledge about what I was trying to do and just make a few iapps.

…

On 6 Jan 2024, at 10:03, Christof Ressi ***@***.***> wrote: On the other hand, I don't think it is reasonable to require open source developers to purchase an Apple Developer ID and notarize their plugins.

[Spacechild1]

I'm already using IEM's Apple ID for codesigning. As a last resort, I will use it to notarize my plugins. But I really want to avoid it as much as I can, mainly because other open source developers may not have easy access to Apple IDs or the necessary knowledge about the notarization process. That's why I am trying to figure out what's going on.

I completely agree, though it seems unavoidable.

Again, I would really like to see some proof. I cannot believe that Apple just stopped supporting the disable-library-validation entitlement without some announcement. After all, there are plenty of existing 64-bit Intel plugins for various software that will never be updated.

[muellmusik]

From the link I posted:Beginning in macOS 10.14.5, software signed with a new Developer ID certificate and all new or updated kernel extensions must be notarized to run. Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized. However, you aren’t required to notarize software that you distribute through the Mac App Store because the App Store submission process already includes equivalent security checks.On 6 Jan 2024, at 10:21, Christof Ressi ***@***.***> wrote: I'm already using IEM's Apple ID for codesigning. As a last resort, I will use it to notarize my plugins. But I really want to avoid it as much as I can, mainly because other open source developers may not have easy access to Apple IDs or the necessary knowledge about the notarization process. I completely agree, though it seems unavoidable. Again, I would really like to see some proof. I cannot believe that Apple just stopped supporting the disable-library-validation key without some announcement. After all, there are plenty of existing 64-bit Intel plugins for various software that will never be updated. It would really great if we could figure out what's going on here. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Spacechild1]

Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized.

This only applies to apps, not necessarily to libraries / plugins. Apps can explicitly choose to allow loading unnotarized libraries by setting the disable-library-validation entitlement. This is what SuperCollider already does.

---

Anyway, I have finally figured out the problem! It would be almost comical, if I hadn't wasted so many hours on this. It has nothing to with Intel vs. Apple Silicon but rather with - hold your breath! - Safari vs. Firefox! The reason I never had problems with unnotarized Ugen plugins was that I always downloaded them with Firefox, whereas most Apple users use Safari.

The issue is that Safari seems to automatically quarantine downloads. As a consequence, unnotarized Ugen plugins downloaded with Safari will refuse to load in SuperCollider. This is particularly infuriating because Apple provides no obvious way for the user to opt-in. With executables, you can at least right-click, open and then choose to open anyway. I wish I had already known this 3 years ago...

---

The "proper" fix is, of course, to notarize the plugins, but I will refuse to do so, for the following reason:

While it would be easy for me (thanks to the people at the IEM!), it is just not reasonable to expect casual open source developers - who might not even own Apple hardware! - to purchase an Apple developer ID and learn about notarization.
Some good souls just want to recompile old plugins for Apple Silicon or share some of their own plugins with other people; they should not be required to deal with this bullshit. Instead, we should raise awareness among Apple users on how to prevent binaries from getting quarantined in the first place (e.g. download files with Firefox) resp. learn how to unquarantine them (e.g. https://git.iem.at/pd/vstplugin#macos-1015).

(As a side note: this is much less of a problem for Pd than for SC because Pd externals are distributed via the Deken package manager, which luckily does not quarantine the files. However, there is still an issue when people try to manually install externals or try to share projects with embedded libraries.)

In the end, there is not much we as SC developers can do about it, except for documenting this issue and raise awareness.

[muellmusik]

Interesting! Perhaps the oft suggested but never implemented extension of Quarks to download UGen binaries when available/appropriate might provide a smoother experience (in more ways than just this).On 8 Jan 2024, at 16:46, Christof Ressi ***@***.***> wrote: Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized. This only applies to apps, not necessarily to libraries / plugins. Apps can explicitly choose to allow loading unnotarized libraries by setting the disable-library-validation entitlement. This is what SuperCollider already does. I have finally figured out the problem! It would be almost comical, if I hadn't wasted so many hours on this. It has nothing to with Intel vs. Apple Silicon but rather with - hold your breath! - Safari vs. Firefox! The issue is that Safari seems to automatically quarantine downloads. As a consequence, unnotarized Ugen plugins downloaded with Safari will refuse to load in SuperCollider. This is particularly infuriating because Apple provides no obvious way for the user to opt-in. With executables, you can at least right-click, open and then choose to open anyway. I wish I had known this already 3 years ago... The "proper" fix is, of course, to notarize the plugins, but I will refuse to do so, for the following reason: While it would be easy for me (thanks to the people at the IEM!), it is just not reasonable to expect casual open source developers - who might not even own Apple hardware! - to purchase an Apple developer ID and learn about notarization. Some good souls just want to recompile old plugins for Apple Silicon or share some of their own plugins to the world; they should not be required to deal with this bullshit. Instead, we should raise awareness among Apple users how to prevent binaries from getting quarantined in the first place (e.g. download files with Firefox) resp. learn how to unquarantine them (e.g. https://git.iem.at/pd/vstplugin#macos-1015). (As a side note: this is much less of a problem for Pd than for SC because Pd externals are distributed via the Deken package manager, which luckily does not quarantine the files. However, there is still an issue when people try to manually install externals or try to share projects with embedded libraries.) Anyway, there is not much we as SC developers can do about it, except for documenting this issue and raise awareness. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>