2012/10/19 Daniel Price <daniel.pr...@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
