symbiosis and the sandbox

[tomerbe]

can symbiosis create a sandbox safe audio component? it seems (though i can't find any definitive word), that apple may start requiring this for logic pro x and garageband x

https://developer.apple.com/library/mac/technotes/tn2247/

tom

[Admiral Quality]

We're having a big mutual bitch-fest about it on KVR.
http://www.kvraudio.com/forum/viewtopic.php?t=364851

It's the first time I've seen every single developer agree on something.

- Mike/AQ

> --
> You received this message because you are subscribed to the Google Groups
> "Symbiosis AU VST" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to symbiosis-au-v...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Magnus Lidström]

I am not perfectly up-to-date with the technical side of sandboxing, but I did run Symbiosis under Audulus (a sandboxed host that is available on App Store) well over a year ago. I did not experience any problems back then with the actual wrapping, but a fair amount of problems with features in my actual plug-ins (e.g. copy-protection, file browsers, online version-checker, authentication and separate preference data per host). Symbiosis still uses the Component Manager for registering Audio Units, and although it has been deprecated for a long time, it apparently still works under 10.9. But it may be something I need to address soon.

This whole sandboxing deal *might* turn really ugly on us plug-in developers. Or not. There are different degrees in hell here depending on how far Apple are determined to take their security paranoia. Up until now, they have not taken it far at all. Logic X still runs Audio Units outside the sandbox (as far as I can tell), and GarageBand seems entitled to big exceptions to the sandboxing model. The only thing I have found with my plug-ins that doesn't work out of the box in GB X is our online licensing system, "Authenticator". I assume it is because sandboxed apps don't have access to "~/Library/Application Support", although they do have read-only access to "/Library/Application Support". I know. Backwards. So we might have to find a reliable way for Authenticator to write our license data to "/Library/Application Support" instead.

But this is how things looks *today*. God knows how they will look in a year or two. Not even Apple knows from what I can tell.

Earlier today I was emailing with a few fellow developers about sandboxing and I'll copy parts of my ramblings here, in case you are interested in my general views on sandboxing.

As plug-ins developers we live in a gray, stinky and neglected area in the world of OS X technology. OS X is application centric, so similar to nuisances like the global Cocoa namespace, sandboxing was not constructed with plug-ins in mind. A plug-in doesn't get his own sandbox, but still have to play nicely in everyone else's. It is frustrating as hell being pushed around like this, and I am not sure we have an end in sight unless we too can become first class citizens in Apple's eyes. I would even argue that the dynamic library model is bad and that we would be better off as true apps, in our own process spaces, launched by the DAWs and controlled via inter-process communications. God forbid the amount of work that would take though. 

I don't believe sandboxing have anything to do with protection against hacking attempts, as I am sure there are million of ways to hack it to pieces if you are into that kind of shit. I'm more inclined to believe that Apple needs sandboxing to steer customers into the App Store. I can accept that the necessity for firewalls between different apps on the App Store, so that they won't have an easy time stealing user data from each other etc. But again, such protection is not even present between plug-ins in a sandboxed DAW. I repeat what has been said many times: we just happen to be in the wrong place at the wrong time. We're collateral damage.

/ Magnus

[Chris Randall]

I have our products working like a charm in Logic X Sandboxed and Garageband X by the expedient of removing our copy protection. (Because fuck it.) 

However, I am butting up against something I can't quite figure out. I'd _like_ to get rid of the warning that Garageband throws where it says "you must lower your security settings to run this plug-in." Even though this is a one-time thing, the chances of us being the only thing to trigger it are quite good, as we all know that Garageband users don't buy many 3rd party plugs. 

Any thoughts on how to add kAudioComponentFlag_SandboxSafe to the description? I tried adding sandboxSafe = YES to the info.plist, but that doesn't seem to have any effect. 

-CR

[Matthew Hill]

I am interested in sandboxing a Symbiosis VST. To start off, I have sandboxed AULab as follows:

https://developer.apple.com/library/mac/qa/qa1483/_index.html

This seemed to work easily. I modified the com.apple.security.temporary-exception.audio-unit-host entitlement from True to False to True to show that this enables me to toggle the question about lowering/raising security levels to allow me to load unsandboxed AUs, thereby effectively disabling the sandbox or enabling it.

I've then attempted to edit my plist as described here:

https://developer.apple.com/library/mac/technotes/tn2247/_index.html

I tried adding both versions of the sandboxing, one where I set the sandboxSafe key, and another where I add a resourceUsage key. Neither of these seemed to do a lot for me. I added a breakpoint at the SymbiosisEntry and this never hits when I try to load my AU within the sandboxed AULab. AULab gives me a -3000 error when trying to load the AUs - I don't know what this means.

I've compiled using the 10.9 SDK. My VST is wrapped using the approach where Symbiosis is embedded into the VST.

My guess as to why I am getting nowhere on load in AULab is that this is due to the changes to the dispatching of AUs in Lion being required when trying to loaded by a sandboxed host (the component manager is not being used anymore):

https://developer.apple.com/library/mac/technotes/tn2276/_index.html

Maybe this means Symbiosis wrapped plugins cannot support a fully sandboxed environment until they use the new entry mechanism. This is supported by a post from Blue Cat here:

http://www.kvraudio.com/forum/viewtopic.php?f=33&t=364851&start=30#wrap

If I've followed this correctly, I think it means it's quite important to update to the new Lion AU API dispatching mechanism so that Symbiosis will allow us to sandbox plugins without having to rely on the host declaring the temporary-exception entitlement. Is that a difficult thing to do, and is it expected to be coming along the pipe, and if so when? It would be great to get the wheels in motion now before Logic X is sandboxed with the exception entitlement causing users to complain, and then later when the exception is removed and we absolutely must sandbox, to be ready with prepared products. I got nowhere looking for the COMPONENT_ENTRY macro which the Lion API upgrade note above mentions, so an pretty lost in terms of doing this myself, and I wouldn't really want to deviate from the main tree anyway.

Matt

ps. I also tried in GarageBand X, no difference really.