Do you have any more information on this?
I do but itās better to get information of this kind direct from the source as it could be covered by NDA.
1 Like
BTW, another heads up -
Seems like any host that is hardened runtime wonāt work without):
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_debugger
(at least with Mojave 10.14.5 or greater)
@dave96 mentioning you as a major host developer as this worth testing before new release.
Ableton Live 10 latest public betas seems to break ability to debug and also Studio One from my testing.
If you disable SIP you should be able to attach a debugger again. Thatās what Iāve observed anyway using Studio One 4.5.4.
Thanks! 
Turning SIP off is a workaround though not a solution. Adding the debug entitlement wonāt hurt the product protection so I guess DAW makers should allow this.
1 Like
It was my understanding that Apple intends that DAW makers will eventually not be able ship a debuggable hardened runtime and get through notarisation. Disabling SIP when required would be a necessity for the special interest group of devs like us that occasionally require this capability. I can see why this makes sense from their perspective.
Have I misunderstood?
You might have more insights with 3Ps and Apple.
I admit I just read the basic documents provided.
Iām now only seeing this vague info:
To avoid receiving this error message, archive (as of Xcode 10.2) or export your app directly from Xcode, or set the
CODE_SIGN_INJECT_BASE_ENTITLEMENTSbuild setting toNObefore building your app for distribution. But only change the build setting when youāre done debugging and ready to distribute, because doing so makes it impossible to debug the binary on a system that uses System Integrity Protection.
To enable debugging a plug-in in the context of a host executable, the host can include the
com.apple.security.get-task-allowentitlement if it also includes theDisable Library Validation Entitlement. Donāt disable library validation for executables that donāt host plug-ins because library validation protects them from loading untrusted code.
But thereās in the document above the com.apple.security.get-task-allow so they should have get-ask-allow?
So I should assume Apple suggests developers should disable SIP?
Arggh! this is confusing 
1 Like
Your link suggests to me that they donāt want people shipping debuggable applications, which makes some sense. Most consumers really donāt need it. Those that do should be OK to enable SIP to override the system enforced protection for a short period of time while actively debugging something, right?
But if I read it correctly, this means that com.apple.security-get-task-allow should be add by hosts? (and should be allowed if com.apple.security.cs.disable-library-validation is set).
I think they mean during plug-in development activities, if required. It reads as though theyāre not thinking of the case that the plug-ins are coming from third parties, rather that they are developed in-house.
1 Like
Iāll just post this hereā¦
1 Like
Yes this is why SIP is really good. I understand where youāre coming from. Personally I think what weāre talking about is a fair compromise between the desire for maximum customer protection vs legitimate power user/developer need with associated and understood risks. If you firmly disapprove flag it up on Radar and in the dev forums.
Hereās the problem. Even as a developer you canāt be sure what every binary is doing on your PC, because you didnāt reviewed the source-code. Thats why SIP, sandboxing, signing, notarization, runtime-hardening etc. exists.
Actually a developer who deactivates security mechanisms, should disconnect his PC from the internet and never ever use or execute any 3rd party software. As a developer you are in a special position, you create binaries, which will be distributed on potentially thousands of other workstations.
3 Likes
If you only deactivate SIP on a dedicated development machine when you require a debugging capability and re-enable it after that then the risk is much reduced. Iām not saying this is an ideal way to work, it isnāt, but we have to find compromises when seeking to balance the different security needs of different users on the same platform.
When even legitimate applications can accidentally wreck /var at random when SIP is not turned on then I do accept there is an issue here. Iām trying to work around the problems as pragmatically as I can. Notarisation isnāt going away, I can see why theyāre making changes for the good of the majority of people; but I do still have a way to work, so I accept it even if Iām not thrilled about it.
So if I understand this correctly, the ideal solution would be that DAW manufacturer published a ādevelopmentā version of their hosts, only accessible to plug-in developers, which enables debugging without having to disable SIP?
1 Like
Yes. Iām not holding my breath.
1 Like
There is no need to disable SIP. There is no need for DAW manufacturers to publish a ādevelopmentā version of their DAWs. You can simply re-sign the app bundle, with the entitlements that you want/need.
7 Likes
That feels somehow scandalous, but I like it 
2 Likes
I was pondering over the same idea this morning while driving to the office 
glad that Iām not the only one
1 Like
How? (I have no experiments with entitlements.) Do I simply to add entries to the .entitlements-file in the App-bundle?