[Interest] Qt 5 and Mac App Store

[Till Oliver Knoll]

2012/10/19 Daniel Price <daniel.price at fxhome.com>:
>> ...
>> Nothing. Plain and simple. (I am not sure to what APIs you are actually referring to, but let's just assume they existed).
>
> I was referring to the security-scoped URLs.

Ah, okay then, but still: if your application *wanted* to be malicious
and, say, delete the file the user has such selected via file dialog,
or maybe even at some later point by "security-scoping" that file and
only delete it "silently" much much later, then the sandbox would not
prevent such a behaviour. Because as I said, the idea of the sandbox
is to prevent you process doing damage if it has been "captured" by
some *other* malicious process.

>
>>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.
>
> Ok I'll provide some examples. The app I was trying to get into the MAS had a completely custom File menu (which was really a widget with a listbox - think of the old MS Office menu). There were no QMenu's involved. The app didn't even have anything in the menu bar. All custom. So a pre-rolled 'recent file' menu like you get in typical Cocoa app .nib file wouldn't have helped.

Okay, so let's not call it QRecentFilesMenu then, but rather just
"QRecentFiles": an API which let's you "add" file paths, set the
number of "recent items" etc., define shortcuts on them, define
actions ("slots") on what should happen when you "trigger the 3rd
entry/file path" etc. - and in a sandboxed Mac app as a side effect
those paths would get "security scoped".

How you would represent those paths in the GUI - be it a plain old
Recent Files menu entry or something as you have described - that
would be handled by your own application logic, or by a
QRecentFilesMenu which would operate "on top" of said "QRecentFiles".

I mean that API would have to be refined, off course, such that it
would also fit into your scenario, but it's just an idea I am drawing
here...


> This same app had the ability to import and export images to disk, using default paths (or ones that had been changed and saved in its preferences). They would all need to be security-scoped.
>
> Another example: QtCreator's Recent Project list, or Recent Session list, or example project list...you get the idea.

They would all be handled by the "abstract API" to handle such "recent items".

>None of these use powerbox so all would have to use security-scoped URLs in order to access those locations between sessions should Creator ever hope to be accepted into the AppStore (not that I'm saying they should bother).

Okay, this is where my understanding of "security scoped URLs" gets
out of sync with what you're saying (disclaimer: I am no expert at
that topic, I just happen to have browsed the Apple docs about this
topic a few weeks ago): to my understanding you can ONLY
security-scope a path which the user has opened through powerbox/a
file dialog! Or in other words: an application can't just
"security-scope" any given path and then happily open it, without the
user ever having *manually* selected that file (or directory
possibly).

So when you say that "Recent Sessions" is not a file the user ever
opened manually, then there is probably no way at all that a sandboxed
application could access that file (unless off course that file was
contained in the sandbox itself) - no matter whether you provide a
"security scope" flag on QFile level or wherever.

However I also remember having read about "Document security scoped
URLs", that is if the user opens a document (a file), and that
document refers to other files (say jpeg photos stored alongside with
that document), then there is an API which also lets you
"security-scope" those files alongside - even though the user has
never explicitly openened them via file dialog, the application is
still allowed to read them the next time.

But I guess that the catch here is that you only get access to those
"side-by-side" files if you open the "document file URL" in the first
place: I don't think the application would be allowed to open the JPEG
file directly (otherwise that would weaken the security concept again:
you could simply "document security scope" the entire hard disk as
soon as the user opens any file, and then you would have access to all
files on the hard disk!)


>> 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. ...
> The Genie was let out of the box long ago. That's just the nature of cross-platform development, it gets hacky. Take a look at all the mac-specific WA_ flags in Qt. They have no effect on other platforms so it's not like you have to #ifdef everything.

I meant exactly those flags ;) I wouldn't mind a flag on QFile level
to say "security-scope that file"! As long as you have control over
which files to "security scope". Still, a "Recent Files" API of some
sort would still be welcome (I am going to have to write that anyway
for my own application sooner or later ;))

> ...
> See my examples. It's not just recent files. It's ANY file (read or write) that user didn't select via a native choose-file dialog in that sessions of the application.

That's exactly what I am not so sure about: I think that is simply not
possible to simply "security scope" a file the user has never opened
via file dialog (powerbox) - unless those files are "document"-related
to some given "main URL". And even then, you most likely could not
open those "document-related" files directly, see my reasoning above.

Maybe someone more in the know could enlighten us here.

Cheers, Oliver