Post

Replies

Boosts

Views

Activity

Reply to IOHIDDevice entitlements
Hi Quinn,I probably don't get you quite right here.Amongst the audio plugin development community there are ongoing discussionsi.e.https://forum.juce.com/t/macos-plugins-in-sandboxed-daw/36999https://forum.juce.com/t/garageband-x-sandboxing/11739and others, which indicate that the entitlements can be successfully set for individual bundles (wether .vst/ .vst3/ .component/ or .aax); this also is in accordance to our own findings - except for IOHIDDevice access, which can't be accessed; even when the sandbox is excepted by setting the plugins com.apple.security.device.usb entitlement.Now, my question is: should this work (i.e. is there something wrong on our side or is there a bug in Apples sandbox)? or is this not suppose to work and how can we achieve in this case IOHiddevice communication from within a sandboxed plugin? So far to me Apples sandboxing does not look being entirely thought thru (what is with other hardware/kext/IOKit access?) but I strongly hope I am wrong here.Having said that, an entire product line is depending on being able to communicate from our audio plugins with our controlling hardware.Or, maybe we are not using the correct (sandbox except-able) API? I see there are more HID related frameworks (i.e. HIDDriverKit.framework vs. IOKit.framework), where we are currently using the later...?!On the other hand, according to the sandbox profiles located at/System/Library/Sandbox/Profiles/application.sbthere seem to be a separate (but nowhere mentioned) "com.apple.security.device.hid" entitlement. Is this the one to use? Can these profiles be "trusted" in any way? Where is the actual documentation?I am blindly tumbling around, waisting my time with simple question... Just because Apples seems to be too ignorrant to provide adequate documentation. Those "maybe this or that" are so tiring and far away from being professional and in the end the cause of bad or wrong development decisions.Thanks & cheers,Hagen.
Feb ’20