KVR Audio

HOFA · Post by **HOFA** » Wed Sep 25, 2013 5:45 am

Thanks for your input, we'll have a look.

We are registered as Apple developer (for the Mac App Store) but on a quick search I didn't find any mentioning of a Logic preview. I will look closer when I have some time. It doesn't seem too urgent at the moment.

Christian

Blue Cat Audio · Post by **Blue Cat Audio** » Thu Oct 03, 2013 11:34 am

What is really bad with sand boxed AUs is that they require to build with the 10.7 SDK or newer, and despite what is said in this note, it is not possible to keep backward compatibility with 10.5 or 10.6 in this case, if you are using C++: the C++ standard library is not backwards compatible between Mac SDKs. So if your minimum target is let's say 10.5, you actually have to force XCode to use the 10.5 SDK, or your plug-in will link against a standard lib that is not available on 10.5... That's a pretty nasty issue that is not documented by Apple but it prevents you from using Apple's backwards compatibility deployment features as soon as you use the STL...

Just in case... Has anyone been able to find a way to bypass this limitation?

Angus_FX · Post by **Angus_FX** » Thu Oct 03, 2013 12:07 pm

Besides, all software should be sandboxed. Totally makes sense from a security perspective.

No, it doesn't. Let your browser and mail programs keep themselves up to date, run a standard user account on any OS released since about 2007. Don't download programs from dodgy sites, open suspicious attachments, or allow shitty Ask Toolbars to install themselves. Run an antivirus/antimalware scanner if needed. Sandboxing at that point is not needed.

Where sandboxing makes sense is if you want to run hundreds of throwaway $2.99 games / novelty apps from developers you've never heard of. But for pro audio software..? Does anyone here see anything massively broken with ye olde Unix permissions model?

AdmiralQuality · Post by **AdmiralQuality** » Thu Oct 03, 2013 6:02 pm

Angus_FX wrote:
Besides, all software should be sandboxed. Totally makes sense from a security perspective.
No, it doesn't. Let your browser and mail programs keep themselves up to date, run a standard user account on any OS released since about 2007. Don't download programs from dodgy sites, open suspicious attachments, or allow shitty Ask Toolbars to install themselves. Run an antivirus/antimalware scanner if needed. Sandboxing at that point is not needed.

Where sandboxing makes sense is if you want to run hundreds of throwaway $2.99 games / novelty apps from developers you've never heard of. But for pro audio software..? Does anyone here see anything massively broken with ye olde Unix permissions model?

Another way to phrase the question. Who here has had their Mac become infected or otherwise compromised by running a commercial audio plug-in? I'd bet nobody. Sandboxing is a "solution" for a problem none of us were having.

This is just yet another shameless attempt by Apple to force sales and monopolize software distribution.

Angus_FX · Post by **Angus_FX** » Fri Oct 04, 2013 9:44 am

Think Different. If it ain't broken, deprecate it.

standalone · Post by **standalone** » Fri Oct 04, 2013 9:55 am

AdmiralQuality wrote:Another way to phrase the question. Who here has had their Mac become infected or otherwise compromised by running a commercial audio plug-in? I'd bet nobody. Sandboxing is a "solution" for a problem none of us were having.

So that "thing" that you said back then was not true after all. Really good to know.

Blue Cat Audio · Post by **Blue Cat Audio** » Fri Oct 04, 2013 5:24 pm

HOFA wrote:I will look closer when I have some time. It doesn't seem too urgent at the moment.

I am worried it might become urgent when OSX Mavericks is released... Which is supposed to be soon, isn't it?

AdmiralQuality · Post by **AdmiralQuality** » Fri Oct 04, 2013 7:45 pm

standalone wrote:
AdmiralQuality wrote:Another way to phrase the question. Who here has had their Mac become infected or otherwise compromised by running a commercial audio plug-in? I'd bet nobody. Sandboxing is a "solution" for a problem none of us were having.
So that "thing" that you said back then was not true after all. Really good to know.

Everything I say is true. (Well, unless I put a winky emoticon beside it to indicate I'm kidding.) Whatever you're accusing me of saying, provide a quote or GTFO.

george · Post by **george** » Thu Oct 24, 2013 7:47 am

Garageband X is now sandboxed. Any success or tips to support plug-ins sandboxing without lowering security settings?

Mushy Mushy · Post by **Mushy Mushy** » Thu Oct 24, 2013 7:58 am

Guys what does sand boxing mean?

Is it effectively the opposite of open-source?

ZenPunkHippy · Post by **ZenPunkHippy** » Thu Oct 24, 2013 8:06 am

Mushy Mushy wrote:Guys what does sand boxing mean?

Is it effectively the opposite of open-source?

Kinda, yeah.

It means an app is "boxed in" and must request permission to access other parts of the OS (disk, network etc.). Permission, in the case of OS X / iOS, is granted by Apple.

It's good for preventing security problems, bad for freedom.

Peace,
Andy.

ZenPunkHippy · Post by **ZenPunkHippy** » Thu Oct 24, 2013 8:10 am

I should add that you can still basically do whatever you want on a Mac. I can compile C++ apps or Python scripts to do anything I want ... within the privacy of my own machine. The problems start when distributing those apps (and, eventually, plugins) to regular Mac users e.g. someone who purchases my app or plugin.

Peace,
Andy.

whyterabbyt · Post by **whyterabbyt** » Thu Oct 24, 2013 9:41 am

Mushy Mushy wrote:Guys what does sand boxing mean?

Is it effectively the opposite of open-source?

Nah, open source means that the underlying code is available to others, so that they can make their own version. sandboxed means it runs in a constrained environment, usually some sort of closed subset of the operating system. open source code could be run sandboxed.

Mushy Mushy · Post by **Mushy Mushy** » Thu Oct 24, 2013 9:52 am

Ah ok cool. Got it now, thanks.

Angus_FX · Post by **Angus_FX** » Thu Oct 24, 2013 10:45 am

Self-contained plug-ins (a compressor with a few GUI resources stored in its bundle, say) should be just fine.

Anything complex with a file system browser (oops, did I say file system? Dirty word nowadays)? Pretty much screwed.

This is part of a push to make all software components self-contained on desktop and iOS, whether or not it's right for the component in question.

For Angry Birds? Sure. Easy & side-effect-free install and uninstall, and no chance of it doing something it shouldn't.

For XCode? Straight up dumb. Making the Mac OS X SDK part of the app bundle is pure stupid.. they've had to brain-damage their own app to make it fit the model. The SDK and the IDE are different components for different purposes & so belong under different hierarchies. (As an aside.. if you're a developer who cares about where all your intermediates & build products get put, they've also made that more difficult. Sure, you can override it, but the default setting show what the intent is: You don't need to know.)

The long term direction and intent is pretty clear, though. Everything on the desktop goes self-contained. Browsing the file-system is no longer to be encouraged, because users have no business thinking in terms of the file-system. User data belongs in the Cloud, whether you like it or not, because Mother knows best, and you, little user, cannot be trusted to look after your own data.

Anyone making "Sandbox-Safe" Audio Units?