[Interest] Qt 5 and Mac App Store

Till Oliver Knoll till.oliver.knoll at gmail.com
Fri Oct 19 16:16:06 CEST 2012


2012/10/19 Daniel Price <daniel.price at fxhome.com>:
> I looked into Security Scoped URLs when I was trying to a Qt app in the MAS a few months back (which is why I brought it up).
>
> These APIs (or rather the ones relevant to sandboxing - file URLs have been around on OSX for years) were only added in the very last version of OSX Lion (10.7.3 if I remember correctly) which was no good to us as we needed Snow Leopard support. It was a showstopper and the project was scrapped. It's also the reason why apps like SourceTree were pulled from the store.

Yes, that's true: "Sandboxing" (even that concept and implementation
thereof exists since at least 10.5) is an evolving process - that
means you can only implement a "Recent Files" menu from 10.7.3 and
onwards. Apple probably likes to see 10.6 die rather sooner than later
:/

(I for my part have still Snow Leopard on my work iMac - Mountain Lion
is just for toying around on the MacBook Pro. However to be fair Apple
corrected many issues they completely did wrong in their "Vista"
release of Lion: it is almost as good as Snow Leopard again ;) But I
am getting OT a bit... )

> But if there are APIs to work around the sandbox, what's to stop any malicious app from just using them instead? I don't get it.

Nothing. Plain and simple. (I am not sure to what APIs you are
actually referring to, but let's just assume they existed).

However that is *not* the point of sandboxing: the sandbox is there so
that you *deliberately* give away permissions, such that when your
application gets exploited by some *other* malicious software it will
get immensely harder to actually exploit the security bug found in
*your* software. Because e.g. you deliberately gave away the
permission for some process to access the file system at all - so why
would you try and circumvent your own restriction?

(I know, I know, my statement is very provocative: the decision to
waive your right to access the file system is not all all that
deliberate - it is forced upon you by the rules of the sandbox. But
protecting the user's files is the most important goal of any sandbox
concept, so if a rule which files your process is allowed to access
was non-existent, then such a sandbox would probably pointless from
the very beginning - oh and yes, "system tools" are then impossible to
implement. But "sandboxing" and "system tool" is almost by definition
a contradiction anyway).

The sandboxing concept assumes that you are a good citizen - that's
why you decided to place your app into a sandbox in the first place
(well, agreed: second place: the App Store is the most likely the
first - and possibly only - reason which makes you place your
application into a sandbox ;))

> We don't need a QRecentFile class. It's not just recent files, that's just an example. What we need is for QFile and handle this automatically; if a user selects a file path through powerbox, it needs to managed a scoped URL for it so that the operation is transparent.

I disagree here: you *don't* want *every* file you ever open via QFile
to be security-scoped! Just like you wouldn't place every file the
process ever opens (config files, temp files, cache, ...) into the
user's Recent Files menu either.

A flag when opening a file which would let you control whether to
"security-scope" a given file path (read/write/security scoped) of
QFile would maybe be okay. But then again you would reflect a very
specific API - which currently only exists on OS X AFAIK - in a
cross-platform API. It is not unprecedented, there are already flags
in the Qt API which are very platform-specific... just saying.

However I wouldn't know why you wanted to "security-scope" a given
file if the intention was *not* to place it into the Recent Files
menu, too - I currently just don't see any other use case than the
"Recent Files". So why not come up with a QRecentFileMenu (which would
be a welcomed class anyway) which would transparently handle the
appropriate platform-specific APIs for us (i.e. be "sandbox-aware")?

Cheers, Oliver



More information about the Interest mailing list