QT app sandboxing for Mac App Store?

[sword726]

Hello,

Mac App Store all apps must sandbox by November.

What can we do to get our qt apps sandboxed?

Thank you

[ChrisW67]

Read this for a long winded discussion culminating in some useful patches to get apps into the store.

[sword726]

Thank you, i read it, but i don't found "sandboxing".

Earlier, the Mac App Store was suggested as a way Apple might expedite the adoption of new Lion technologies. In the case of sandboxing, that has already happened. Apple has decreed that all applications submitted to the Mac App Store must be sandboxed, starting in November.

Data:
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/ApplicationSandboxing/ApplicationSandboxing.html

[ChrisW67]

The patches in the thread directly address existing (involuntary) Qt actions that violate the rules, i.e. "sandbox". If Apple are moving the walls on the walled garden again then perhaps Qt will need further patching (probably not). The vast majority of application behaviour that violates Apple's rules is programmer controlled. A Qt application is just like every other application and you will have to jump through the same (moving) hoops as everyone else. You'll need to sign your code, use certain directories, etc. This isn't Qt's problem

[Oliver Knoll]

The patches in the thread directly address existing (involuntary) Qt actions that violate the rules, i.e. "sandbox".

No, that thread does not address any "sandbox" issues: "sandboxing" is an additional concept which exists besides the "Mac App Store Rules" (which will include the requirement that apps will need to be sandboxed as of November 2011, as the OP correctly noted). That thread was all about preventing Qt from violating other rules which had to do where an application is allowed to store config/data/cache files. That has nothing to do with sandboxing.

Sandboxing is all about specifying entitlements to your application.

Sandboxing is described in the link the OP gave. In fact, these steps describe "post-build" steps and apply to any application, regardless whether it is implemented in Qt or "natively" in Cocoa (or any other language/framework). It basically boils down to a) codesign your application and b) provide an entitlement property list file.

Given that, I followed the steps described by Apple, giving my application the single entitlement "com.apple.security.documents.user-selected.read-write", that is, the application is only allowed to read/write from/to files explicitly chosen by the user.

According to the Apple docs there exists a daemon "PowerBox" which is supposed to render the file dialogs in a separate process: "Any time an application running inside a sandbox invokes an NSOpenPanel or NSSavePanel dialog, rather than showing the panels directly, AppKit automatically asks the Powerbox to present the dialog. From a developer perspective, there are no code changes required in terms of how these panels are used; this process is fully transparent."

However when I try to open a native QFileDialog (as a window sheet) my application crashes! Details can be found in my post to qt-interest, archived here: http://permalink.gmane.org/gmane.comp.lib.qt.general/43484

I am not sure yet whether I got the codesigning right, however the Process Monitor claims that my process runs indeed in a sandbox and the Qt and my own preference files are written into the proper ~/Library/Container/my.app.identifier

Seems like sandboxing a Qt application - I tried both Qt 4.7.3 and latest Qt 4.8.0 Beta Cocoa - does not run smoothly "out of the box".

Anyone succeeded in sandboxing a Qt application with the mentioned file read/write entitlement?

Thanks,
Oliver