macOS Catalina : software notarization ... ?

[Zaphod (giancarlo)]

My thoughts.. but we should be sure I interpreted those warnings correctly

[Zaphod (giancarlo)]

This is exactly what apple wants to prevent, but I don't see how they could stop it: if a plugin needs this feature it is forced to connect to a component (app or system extension) with the relaxed security signature. At this point you could inject the component.
Just speculating, here

[Wallander]

Well, that's probably good news: if no almost no third party plug-in can be loaded by Logic (which will probably be the case without this flag), you can be sure they'll have to relax their policy!

Isn’t that problem isolated to PACE protected plugins? PACE wants relaxed entitlements, in order to produce and run unsigned executable code in realtime:

https://developer.apple.com/documentati ... ble-memory

That’s probably going to go sooner or later...

But there’s another relaxed entitlement. It allows a hardened runtime host to load arbitrary plugins and frameworks, even those that aren’t signed:

https://developer.apple.com/documentati ... validation

That sounds like a requirement for any host, even for Logic. Otherwise you can only load plugins signed by Apple or by the same team ID as the host.

[Zaphod (giancarlo)]

So you have to same concerns we have
Also I don't think logic will relax those (unsigned code in memory) entitlements, but I would be HAPPY to be wrong this time.
The entitlement is about a specific method of dyld, deprecated in 2006, Mac osx 10.5 and survived till... 10.14

It is NOT related to pace only. Most of protections are based on virtualization and loading of unsigned or self modifying code
It is the same method used by trojans, malware, cracks. But they will find an other way easily, there was an article about faking staples and signatures without submitting to apple

[discoDSP]

But they will find an other way easily, there was an article about faking staples and signatures without submitting to apple

source?

[Zaphod (giancarlo)]

But they will find an other way easily, there was an article about faking staples and signatures without submitting to apple

source?

https://lapcatsoftware.com/articles/notarization.html

[Zaphod (giancarlo)]

Double

[Zaphod (giancarlo)]

It is based on modifying the quarantine attribute

[discoDSP]

Thanks. Very fair points on the article. I still think this notarization thing is a big hassle for developers and brings very little to "protect" the end user.

[Wallander]

It is NOT related to pace only. Most of protections are based on virtualization and loading of unsigned or self modifying code
It is the same method used by trojans, malware, cracks. But they will find an other way easily, there was an article about faking staples and signatures without submitting to apple

Understood. I don't actually know much about that.

I think it's safe to assume that advanced forms of copy protection, involving the same mechanisms which may be exploited for malware, is not a long-term solution for any platform owned by Apple.

[Wild Hades]

There is something I really don't understand, I hope someone has a clue here.
Several days ago PACE sent an email with a lot of deails on the matter, and among them this warning:
...

I've built a plug-in just yesterday using Pace protection and got it notarized successfully.
It seems to work without issues on OSX 10.14.6 using Logic X 10.4.6 but I have yet to find someone brave enough to upgrade to Catalina and try it

Other things I've noticed:
- The plug-in is built using 10.7 as target, but the notarization succeeds even if minimum is supposed to be 10.9 according to Apple (unless I'm mistaken)
- When building a Standalone app and enabling Runtime Hardening, adding the Audio Input entitlement seems not to be enough to have access to the microphone/soundcard input, I've only got it to work after upgrading my Projucer and enabling the microphone access flag, which I think just adds the NSMicrophoneUsageDescription key to the plist file

Hope it helps,
Federico

[Wallander]

There is something I really don't understand, I hope someone has a clue here.
Several days ago PACE sent an email with a lot of deails on the matter, and among them this warning:
...

I've built a plug-in just yesterday using Pace protection and got it notarized successfully.
It seems to work without issues on OSX 10.14.6 using Logic X 10.4.6 but I have yet to find someone brave enough to upgrade to Catalina and try it

Other things I've noticed:
- The plug-in is built using 10.7 as target, but the notarization succeeds even if minimum is supposed to be 10.9 according to Apple (unless I'm mistaken)
- When building a Standalone app and enabling Runtime Hardening, adding the Audio Input entitlement seems not to be enough to have access to the microphone/soundcard input, I've only got it to work after upgrading my Projucer and enabling the microphone access flag, which I think just adds the NSMicrophoneUsageDescription key to the plist file

Hope it helps,
Federico

You only need to link against the 10.9 SDK, but you can still have an older deployment target (I target 10.6). Here’s what Apple says:

”Because of significant differences in the way code signing works prior to macOS 10.9 (see Code Signing Changes in OS X Mavericks 10.9), notarization only works for binaries linked against macOS 10.9 or later. If you use an older SDK, notarization fails and reports an issue with the following message:

The binary uses an SDK older than the 10.9 SDK.

Using a newer SDK doesn’t affect your binary’s compatibility with earlier versions of macOS. Instead, version compatibility depends on the app’s deployment target, as described in Edit deployment info settings.”

[Zaphod (giancarlo)]

It is NOT related to pace only. Most of protections are based on virtualization and loading of unsigned or self modifying code
It is the same method used by trojans, malware, cracks. But they will find an other way easily, there was an article about faking staples and signatures without submitting to apple

Understood. I don't actually know much about that.

I think it's safe to assume that advanced forms of copy protection, involving the same mechanisms which may be exploited for malware, is not a long-term solution for any platform owned by Apple.

I understand several deprected things are going to be removed, but we need alternatives.
I can't imagine a single OS which is preventing just in time compilers, memory loading dynamic libraries and all the stuff normally required for building a virtual machine.
For sure there is a way for allowing stuff and checking it is not doing something weird outside its space (so it can sandoboxed). In our case we use virtual code for doing calculations, it is way different than builinding a ramsonware (which has access to external files).

[Zaphod (giancarlo)]

There is something I really don't understand, I hope someone has a clue here.
Several days ago PACE sent an email with a lot of deails on the matter, and among them this warning:
...

I've built a plug-in just yesterday using Pace protection and got it notarized successfully.
It seems to work without issues on OSX 10.14.6 using Logic X 10.4.6 but I have yet to find someone brave enough to upgrade to Catalina and try it

Other things I've noticed:
- The plug-in is built using 10.7 as target, but the notarization succeeds even if minimum is supposed to be 10.9 according to Apple (unless I'm mistaken)
- When building a Standalone app and enabling Runtime Hardening, adding the Audio Input entitlement seems not to be enough to have access to the microphone/soundcard input, I've only got it to work after upgrading my Projucer and enabling the microphone access flag, which I think just adds the NSMicrophoneUsageDescription key to the plist file

Hope it helps,
Federico

testing things on 10.14 is way different than testing things on 10.15
Apparently (I have to complete my checks) in actual catalina beta loading unsigned code in memory is not allowed any more, even if the application is not hardened. You need to harden it and set explicitly the flag.

I see several things are not working in plugins coming from other vendors, but I'm not sure it is related with this issue or other ones.
My guess: if pace asked for it, maybe the flag is necessary, sooner or later. It seems like it is necessary at the very beginning. I hope my info are correct and are not creating panic or confusion.

[Wallander]

I understand several deprected things are going to be removed, but we need alternatives.
I can't imagine a single OS which is preventing just in time compilers, memory loading dynamic libraries and all the stuff normally required for building a virtual machine.
For sure there is a way for allowing stuff and checking it is not doing something weird outside its space (so it can sandoboxed). In our case we use virtual code for doing calculations, it is way different than builinding a ramsonware (which has access to external files).

I don’t know how these things are implemented.

But if I understand things correctly, Hardened Runtime only prevents you from creating JIT machine code, to run natively on the CPU. They don’t (and can’t) stop you from creating a virtual machine, or an interpreter. A VM is not a security issue, because the VM or interpreter is bound by the Hardened Runtime, whereas unsigned native machine code has privileges beyond the original app.