Originally Posted by cdale
after arguing that those developers concerns are all FUD you point us to a web item (which strangely, I'd already read, remember my referring to concerns expressed on the internet?) from a developer
who express concerns over the sandbox, recommends that Apple should "make an exception
" in the MAS for legitimate code that doesn't run under it (Apple have not done so in any general sense, some apps are apparently being forced to reduce functionality due to sandbox bugs
if they wish to stay in the MAS - exactly what Shipley talks about), and concludes that Apple should make certificates available to developers so they can sign apps (including non-sandboxed) outside the MAS - and that is what Apple has just done.
So in short you agree its not all FUD and the Apple move addresses some, but not all, of the sandbox limitations.
And your point in calling it all FUD was?
Because all the sandboxing doom and gloom calls ignore that Apple implemented as part of it's security strategy almost EXACTLY what Wil was saying was the right solution. I see a very different article that you do, reading the same text.
Part 1 was a commentary that last November Apple wasn't done and it looked like a hard job. So? The section was completely void of any difficulties for developers, he pretty much only pointed out difficulties for Apple in making entitlements available, I didn't see anything that said developers will be screwed. So no FUD in that section and nothing there to support the FUD crowd. Well it isn't easy for Apple to implement, but I don't agree it is quite as hard as Wil was making it out to be. It also isn't as critical to be 100% effective or go home as he thinks it is. It just needs to be damn effective. And inevitable holes get plugged as they get found. It would be ridiculous for Apple to not do anything with sandboxing just because it's hard to implement. So I'll agree he isn't a sandbox supporter, but the why is important, and the why boils down to hard for Apple -- not difficulty for devs.
Part 2 was red herring for anyone who thinks it says anything about sandboxing. It says nothing about sandboxing, it only says the obvious-to-any-CS-major ~you cannot analyze a program and know with a guarantee that it will never do bad things.~ Becaue that is a version of the Halting Problem, and very true. This is actually a reason for implementing both sandboxing and code signing, specifically because of the Halting Problem. Anyone trying to use Part 2 as ammunition against sandboxing was completely missing the reason he wrote it was to set up his part three -- certificates (non-MAS code signing).
Part 3 literally is what Apple has done for the non-MAS crowd. Specifically because Apple knows 3rd party hardware drivers cannot live with MAS sandbox limits, and also that not all Apps on OS X will be properly sandboxable for the first year or three, or maybe the devs won't have the budget to move into a sandbox before the next big rev. So code signing is an active part of the sandbox security effort even though it lies outside of the sandboxes. It allows users to feel all fuzzy even though they didn't get the same set of security assurances from Apple as sandboxed apps have, because the code signing dev has been stand-up about being in the community as a responsible player.
I don't see how anyone can actually read the full article as contributing to anti-sandbox FUD. I only see that sandbox FUD deployers took a few out of context sentences and wrapped their own words around those isolated sentences to try to make it look like Wil said sandboxes are bad. He said no such thing, at best he said he liked code signing more, and I never saw him say he couldn't work within whatever framework Apple put in front of him.
I agree with all his factual callouts, and only differ on the opinions of how hard it might or might not be to implement in the short term, and that I think it is valuable even if there are some early holes that will need to be found and plugged. I look at iOS and see 4+ years of Darwin based sandbox technology so the OS X sandbox implementation is far from starting from scratch with zero feedback to date. A lot of the basic architectural kinks have already been ironed out from iOS work and the more OS X and iOS converge the more that iOS sandbox experience helps.
Make more sense now?