

An Embarrassing Bug in Mac App Sandboxing - tumultco
http://blog.jmfd.me/an-embarrassing-bug-in-mac-app-sandboxing/

======
kybernetyk
Sandboxing is utterly broken. If you want a real hellride try to load 'sandbox
unsafe' Audio Units (read: every non-Apple AU, though many Apple AUs aren't
safe either) into a sandboxed application.

There's a temporary entitlement that should allow this. The only problem is,
that this entitlement simply disables sandboxing midway through app
initialization and the NSUserDefaults system becomes unusable after that.

See last post in: <https://devforums.apple.com/thread/155950?tstart=0>

~~~
coldtea
> _Sandboxing is utterly broken. If you want a real hellride try to load
> 'sandbox unsafe' Audio Units (read: every non-Apple AU, though many Apple
> AUs aren't safe either) into a sandboxed application._

How does that prove that sandboxing is broken, much less "utterly"? You should
NOT be able to load unsafe AUs into a sandboxes application.

And I'm not sure "temporary entitlement" was developed to allow this kind of
thing. Sounds like an abuse of it.

~~~
kybernetyk
> I'm not sure "temporary entitlement" was developed to allow this kind of
> thing. Sounds like an abuse of it.

The entitlement is called 'com.apple.security.temporary-excaption.audio-unit-
host'.

~~~
coldtea
LOL. In this case, it sounds like a really by-the-book use of it.

In also sounds like a kludge way to solve the AU sanboxing issue from Apple's
part.

------
jared314
I thought there was a way to report these issues to Apple without a public
letter. Also, the use of "embarrassing" to describe an unfortunate bug makes
this feel like a disingenuous PR stunt.

~~~
tumultco
We reported this to Apple (that's what the rdar:// link is for, to add to the
Radar bug tracking system). The "embarrassing" perhaps stems from our
frustration and months of dealing with similar issues, but is something that
should have easily been uncovered if apple did dogfooding of the technology
before forcing it on developers.

I wrote it up as more of a public service announcement to other Mac developers
who might be encountering the same issue.

~~~
coldtea
> _The "embarrassing" perhaps stems from our frustration and months of dealing
> with similar issues, but is something that should have easily been uncovered
> if apple did dogfooding of the technology before forcing it on developers._

The technology was obviously tested by Apple --they didn't just put something
out there--, and it was also available for third party testers to test with
the betas.

If nobody had found it at that point, why would Apple? Maybe it's not as
common as you think.

------
zyb09
Just report and it surely will get fixed. No need to call it out as
"embarrassing". Especially not as an Software Developer yourself, like you
never had any stupid bugs in your code, right?

~~~
tumultco
I've shipped plenty of embarrassing bugs in my days! And, had I shipped a bug
that likely has to do with escaping characters improperly, I too would have
been embarrassed by it. But beyond that, as someone who spent many years
dealing with integration testing of Mac OS X, this is the type of bug that
would make me cringe that our infrastructure was not setup to catch it.

~~~
echaozh
All bugs are embarrassing. What one can only do is to argue whether it's a bug
or a feature.

------
dubcanada
This is really worded funny. It's not embarrassing to Apple if you post it.
It's only embarrassing if they determine it to be embarrassing and as far as I
am concerned this is an extremely small use case.

Also can you PLEASE stop saying HTML5. It's soo annoying. HTML5 IS HTML. It
could be HTML3 the bug would still appear :)

~~~
typicalbender
How is this a small use case? I know a number of people including myself who
have spaces in folder name, especially when trying to keep things organized
(for example a folder in applications called Web Development would trigger
this bug). For a company as large as Apple supporting an infrastructure as
large as its app store this most definitely should have been caught long
before release.

~~~
coldtea
> _How is this a small use case? I know a number of people including myself
> who have spaces in folder name_

If you know a lot of people, including yourself, that uses spaces in folder
names

AND

none of them has seen this bug all this time with sandboxing, including tons
of developers doing the early/beta testing of sandboxing

then IT IS a small use case.

~~~
typicalbender
I didn't say that I or the people I know use OSX. However I made the
assumption that Linux and Windows users were similar enough to OSX users in
the ways they organize their stuff. Putting the size of the use case aside, It
just surprises me that something like this would make it into a production
system supporting 10s of thousands of apps and number of which have spaces in
their names.

------
coldtea
> _Sandboxing is required by Apple to be on the Mac App Store. The technology
> has caused us and our users grief, cost significant development time, and
> likely lost our business users._

Maybe due to incompetence? On their part I mean.

For one, you are not required to be "on the Mac App Store". You can continue
to sell your app outside of it. Heck, very successful apps are sold outside of
it, from MS Office and Creative Suite to most of the stuff Rogue Amoeba does.

Second, tons of other apps seem to do just fine on the app store. What exactly
makes your app an exception?

~~~
tumultco
We do distribute and sell independently of the Mac App Store, which allows us
to offer trials, lets users to easily convert the trial to a licensed copy,
and provide bulk or educational discounts. Even with that, ~80% of our revenue
has come from the Mac App Store. Users want and expect software to be
available on the Mac App Store; I'm sure the support volume we'd get by not
being there would far outweigh any we've seen from this bug.

Sandboxing was a technology that did not exist (and therefore was not
required) when we started selling on the Mac App Store. This came later, and
became a requirement to push any updates containing features.

Lots of mac developers have complained publicly (or privately to me) about
sandboxing. Many others have not been able to issue updates, removed major
features, or simply removed their apps from the store. There's plenty of
information on this on blogs or the developer forums, though many would not
speak out publicly against the hand that feeds them. The apps that do well
with sandboxing are naturally those which do the least. It would have been
easier for us to neuter our app, but we've taken a strong approach to working
through all the issues and avoided removing any major features. It would be
unfortunate if innovation was sacrificed for security.

We originally planned to have our non-MAS copy not be sandboxed. This creates
complications and other bugs for users when offering both versions based on
how the sandbox container is maintained and that any bookmarks (aliases) kept
cannot interoperate between the two. From all the tradeoffs we see, fully
adopting sandboxing is the best option. But, that won't stop me from
complaining about all the bugs!

~~~
coldtea
Fair enough.

I might came off as a little harsh, but I've seen a lot of "X API is awful"
posts before with little content besides some grips and one/two bugs" (which
all APIs have).

------
ajasmin
Does anyone have a theory as to what may be causing this bug?

~~~
martinced
Some tokenization not working correctly?

I'm pretty sure this as to do with "TextEdit" being processed as "TextEdit"
and "Text Edit" being processed as "Text" and "Edit" (and maybe neither "Text"
nor "Edit" being allowed, while "Text Edit" is whitelisted but for whatever
reason tokenization screwed up).

"Whitespace in filename/dirname" issues are typically tokenization issues in
3rd party scripts. Here it's probably related to some bogus lookup in some
blacklist/whitelist.

------
DannoHung
Huh, thought it was going to be a security vulnerability based on that title.

~~~
akaiser
Let's wait for someone to find a vulnerability based on that bug then. Ideas,
anyone?

------
martinced
Not commenting on the sandboxing but...

Writing _very_ strict coding guidelines and specs enforced at build time is a
real time saver. For example we're using a script which verifies that all of
the files/directories we've got control on are only using a subset of ASCII.

If you're a programmer working on the server-side, you have complete control
on the naming of files.

Why is it a godsend to use such anal specs? Because _external_ utilities /
scripts, on a variety of OSes, will work flawlessly on your files. Otherwise
it's all too common to have quoting / escaping issues with this or that script
/ tool / utility not correctly dealing with space on this or that platform.

When you're forced to let the client pick filenames, things gets a bit
trickier. But I still do advice very strict naming conventions for all the
files that you have control upon.

Anyone not admitting that a space in a filename can be problematic hasn't been
in this business long enough. _(Hint: the problem is not what you have control
upon, but what you don't have control upon... And that very article is_
precisely* proving my point).

~~~
ajross
Exactly. Allowing end users to put spaces into end user document names is a
fine feature. Allowing developers to do it is just dumb. There are far, far
too many tools ( _really useful tools_ , if someone is tempted to argue this
bit: please don't, you're simply wrong and I won't engage) out there that
presume that path lists are split on whitespace.

