Re: More sandblasting (oops, I mean sandboxing die die die)
Re: More sandblasting (oops, I mean sandboxing die die die)
- Subject: Re: More sandblasting (oops, I mean sandboxing die die die)
- From: Alex Zavatone <email@hidden>
- Date: Mon, 03 Sep 2012 19:04:56 -0400
On Sep 3, 2012, at 6:44 PM, Todd Heberlein wrote:
>
> On Sep 3, 2012, at 2:58 PM, William Squires <email@hidden> wrote:
>
>> I can see the benefit of taking a more security-related stance on a closed platform like iOS so as to make writing malware harder, but for a general-purpose computing platform, this'll just put unnecessary roadblocks in the way of newbies who want to develop for it… Unless Apple's geniuses can figure out a way to simplify the whole shooting match to a one-click solution! :)
>> ...
>> As it is, there's a whole sh*tload of steps between 2 and 4 now (and that replace step 3). Boo!
>
> I see two problems Apple must address. The first is similar to your list. Key management is a real pain. I just started compiling code on a new machine and couldn't figure out why I couldn't properly sign my code. I looked and I had the developer certificates in my keychain.
The issue here is that we as Apple users, (not developers) are used to processes being somewhat forgiving.
If you screw up at once point in the chain, with certs and keys, you are screwed. There needs to be a step by step checklist that guides your through the whole process and a chart that illustrates what needs to be in place and if there is a failure anywhere within the steps, what you are likely to expect. Then we/someone makes a reverse lookup that says "if you have this problem", these are the possible reasons why.
Currently, this is a mess of a process that ends up wasting immense amounts of time. It's not painfully obvious that you're really got to start over, or at which part you need to start from, to get this to work every time.
Also, after adding devices to prov profiles, it's not painfully obvious that those devices are hardcoded in the profiles, the current profile on your Mac (or on your team's macs) doesn't automatically lookup and include the new devices, which seems rather straightforwards to do.
> The problem was that I didn't have the private keys too. I went back to my old development machine, exported the certificate and private key combo, and imported them into my new machine. Bingo, the problem is solved.
>
> I *really* *really* wish that this workflow process was simpler and easier to debug. It would have helped if Xcode would be smarter than me and say, "Dummy, you have your developer certificates but not your private key. You need to sign code with the private key. Go get it. Here is a link explaining the process <link>."
I agree. It's a painful time wasting mess.
We expect much better of Apple and Apple's processes.
> Outside the issue of getting and managing private keys and public certificates, the process of Sandboxing is non-trivial. Apple is trying to capture "user intent" in code that is running outside your code, but "user intent" is kind of a nebulous concept. For file access, the primary approach is their PowerBox. For simple document-type apps this solution works OK, but there are a lot of cases where it fails.
>
> There are far more talented and experienced Mac programmers than me who are running into limitations and planning on taking their next versions out of the Mac App Store (or so I've read). I hope they are able to provide constructive criticism to Apple for improving the current solution.
>
>
> CONCLUSIONS:
>
> (1) I wish Apple could simplify the key management process and make resolving problems easier. Key management is a baffling process to most people.
>
> (2) I hope Apple listens to constructive criticism on improving their approach to capturing user intent. ("constructive" being the operative word)
>
> Todd
Well, the point is that when criticism gets beyond constructive, this should tell Apple just how frustrating and counterproductive the process actually is.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden