[Moderator] Sandboxing die.die.die

[Scott Anguish]

Seems I made a typo that has confused one or two people

This discussion is NOT appropriate for this list.

So please take it elsewhere

thanks.

Scott

On Sep 1, 2012, at 12:11 AM, Scott Anguish  wrote:

> This has gone far enough.
> 
> The thread is closed. It is appropriate for this list.
> 
> 
> On Aug 31, 2012, at 5:29 PM, Jeffrey Oleander  wrote:
> 
>>> From: davel...@mac.com 
>>> To: cocoa-dev@lists.apple.com
>>> Date: Thursday, 2012 August 30, 18:26
>>>> On 2012 Aug 30, at 18:09, z...@mac.com wrote:
>>>>> From: Jeffrey Oleander 
>>>>> Thu, 2012 Aug 30 13:57:44 
>>>>> To: 
>>>>> Subject: Re: Sandboxing die.die.die 
>>>>> Sandboxing die.die.die
>>>>> Code-Signing die.die.die
>>>>> Javascript die.die.die
>>>>> Kludgey CPUs die.die.die
>>>>> Bodyshopping die.die.die
>> Contextless docs die.die.die
>>>>> (throwing hammer at hare-brained power-mad forces of
>>>>> evil)
>>>>> 
>>>>> Now, when can we cut the chains and get back to
>>>>> developing great apps?
>> 
>>>> Easy. When the exact items that we have issues with
>>>> are addressed.
>>>> 
>>>> It's not that hard. Listen to the developers and
>>>> fix what causes the most problems for them. 
>>>> 
>>>> You satisfy their needs and as a result have
>>>> developers creating great apps easier and faster.
>>>> 
>>>> If you don't do this, then the focus from management
>>>> is in the wrong place.
>> 
>>> But you're tilting at windmills here.
>> 
>> Cervantes... Don Quixote de la Mancha charging at
>> what he thought was an evil, force and fraud initiating
>> knight, but, in reality attacking a wind-mill.  That's 
>> not the case, here.  (Why do so many people mis-apply
>> that expression to deride others' efforts to improve
>> things?)
>> 
>> These are actual design flaws and bugs, and lack of 
>> clarity completeness and context in docs.
>> 
>>> This is not an official support channel. File Radars
>> 
>> I would but it's broken... again.  Hence:
>>>> Javascript die.die.die
>>>> Javascript die.die.die
>> 
>> On the plus side, display manufacturers have made
>> larger, higher res displays.  Yay.  OTOH, who can
>> afford them in this approximately 13th year of the 
>> Bush-Clinton-Bush-Obama economic depression.  raspberries.
>> 
>> OT3H, all past bug reports and requests for improvements
>> in docs have gone to the bit bucket.  Not corrected,
>> just closed, rarely acknowledged.
>> 
>> I used to do tech support.  I've worked on ticketing/
>> bug report systems.  I've seen developers and tech writers
>> do such things in the past.  The only real solution is
>> for someone within the company to be given enough clout
>> to see that the bugs are actually corrected before the
>> ticket gets closed.  The usual pattern is for it to get
>> worse and worse over a period of a decade or more before
>> someone comes along to clean house.
>> 
>> But I don't expect miracles.  Apple has high revenues,
>> so some folks are satisfied with what they're getting
>> for now, and I get the impression there are lots of 
>> newbie developers willing to put up with draconian 
>> nonsense just to have the chance to develop at all.
>> 
>> Until the bugs and design flaws and docs are all corrected, 
>> I'll continue grumping by whatever channels are open, 
>> thankyouverymuch, though I do refrain for long periods --
>> often years at a stretch -- so as not to jam the lines 
>> of communication.  I'm making an exception, this time,
>> by posting twice, simply because there's quite a bit of
>> spill-over aggravation from the US (and UK) politicians 
>> of several parties striving mightily to make STEM job 
>> markets worse in this political cycle.
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
>> 
>> This email sent to sc...@cocoadoc.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
> 
> This email sent to sc...@cocoadoc.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Moderator] Sandboxing die.die.die

[Scott Anguish]

Correction, a typo, it is NOT appropriate for this list.


On Sep 1, 2012, at 9:42 AM, Alex Zavatone  wrote:

> 
> On Sep 1, 2012, at 12:11 AM, Scott Anguish wrote:
> 
>> This has gone far enough.
>> 
>> The thread is closed. It is appropriate for this list.
> 
> It is appropriate for this list.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
> 
> This email sent to sc...@cocoadoc.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Moderator] Re: Sandboxing die.die.die

[Alex Zavatone]

On Sep 1, 2012, at 12:11 AM, Scott Anguish wrote:

> This has gone far enough.
> 
> The thread is closed. It is appropriate for this list.

It is appropriate for this list.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [Moderator] Re: Sandboxing die.die.die

[Eagle Offshore]

Did you mean INappropriate?

Sent from my iPhone

On Aug 31, 2012, at 21:11, Scott Anguish  wrote:

> This has gone far enough.
> 
> The thread is closed. It is appropriate for this list.
> 
> 
> On Aug 31, 2012, at 5:29 PM, Jeffrey Oleander  wrote:
> 
>>> From: davel...@mac.com 
>>> To: cocoa-dev@lists.apple.com
>>> Date: Thursday, 2012 August 30, 18:26
>>>> On 2012 Aug 30, at 18:09, z...@mac.com wrote:
>>>>> From: Jeffrey Oleander 
>>>>> Thu, 2012 Aug 30 13:57:44 
>>>>> To: 
>>>>> Subject: Re: Sandboxing die.die.die 
>>>>> Sandboxing die.die.die
>>>>> Code-Signing die.die.die
>>>>> Javascript die.die.die
>>>>> Kludgey CPUs die.die.die
>>>>> Bodyshopping die.die.die
>> Contextless docs die.die.die
>>>>> (throwing hammer at hare-brained power-mad forces of
>>>>> evil)
>>>>> 
>>>>> Now, when can we cut the chains and get back to
>>>>> developing great apps?
>> 
>>>> Easy. When the exact items that we have issues with
>>>> are addressed.
>>>> 
>>>> It's not that hard. Listen to the developers and
>>>> fix what causes the most problems for them. 
>>>> 
>>>> You satisfy their needs and as a result have
>>>> developers creating great apps easier and faster.
>>>> 
>>>> If you don't do this, then the focus from management
>>>> is in the wrong place.
>> 
>>> But you're tilting at windmills here.
>> 
>> Cervantes... Don Quixote de la Mancha charging at
>> what he thought was an evil, force and fraud initiating
>> knight, but, in reality attacking a wind-mill.  That's 
>> not the case, here.  (Why do so many people mis-apply
>> that expression to deride others' efforts to improve
>> things?)
>> 
>> These are actual design flaws and bugs, and lack of 
>> clarity completeness and context in docs.
>> 
>>> This is not an official support channel. File Radars
>> 
>> I would but it's broken... again.  Hence:
>>>> Javascript die.die.die
>>>> Javascript die.die.die
>> 
>> On the plus side, display manufacturers have made
>> larger, higher res displays.  Yay.  OTOH, who can
>> afford them in this approximately 13th year of the 
>> Bush-Clinton-Bush-Obama economic depression.  raspberries.
>> 
>> OT3H, all past bug reports and requests for improvements
>> in docs have gone to the bit bucket.  Not corrected,
>> just closed, rarely acknowledged.
>> 
>> I used to do tech support.  I've worked on ticketing/
>> bug report systems.  I've seen developers and tech writers
>> do such things in the past.  The only real solution is
>> for someone within the company to be given enough clout
>> to see that the bugs are actually corrected before the
>> ticket gets closed.  The usual pattern is for it to get
>> worse and worse over a period of a decade or more before
>> someone comes along to clean house.
>> 
>> But I don't expect miracles.  Apple has high revenues,
>> so some folks are satisfied with what they're getting
>> for now, and I get the impression there are lots of 
>> newbie developers willing to put up with draconian 
>> nonsense just to have the chance to develop at all.
>> 
>> Until the bugs and design flaws and docs are all corrected, 
>> I'll continue grumping by whatever channels are open, 
>> thankyouverymuch, though I do refrain for long periods --
>> often years at a stretch -- so as not to jam the lines 
>> of communication.  I'm making an exception, this time,
>> by posting twice, simply because there's quite a bit of
>> spill-over aggravation from the US (and UK) politicians 
>> of several parties striving mightily to make STEM job 
>> markets worse in this political cycle.
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
>> 
>> This email sent to sc...@cocoadoc.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/eagleoffshore%40mac.com
> 
> This email sent to eagleoffsh...@mac.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[Moderator] Re: Sandboxing die.die.die

[Scott Anguish]

This has gone far enough.

The thread is closed. It is appropriate for this list.


On Aug 31, 2012, at 5:29 PM, Jeffrey Oleander  wrote:

>> From: davel...@mac.com 
>> To: cocoa-dev@lists.apple.com
>> Date: Thursday, 2012 August 30, 18:26
>>> On 2012 Aug 30, at 18:09, z...@mac.com wrote:
>>>> From: Jeffrey Oleander 
>>>> Thu, 2012 Aug 30 13:57:44 
>>>> To: 
>>>> Subject: Re: Sandboxing die.die.die 
>>>> Sandboxing die.die.die
>>>> Code-Signing die.die.die
>>>> Javascript die.die.die
>>>> Kludgey CPUs die.die.die
>>>> Bodyshopping die.die.die
> Contextless docs die.die.die
>>>> (throwing hammer at hare-brained power-mad forces of
>>>> evil)
>>>> 
>>>> Now, when can we cut the chains and get back to
>>>> developing great apps?
> 
>>> Easy. When the exact items that we have issues with
>>> are addressed.
>>> 
>>> It's not that hard. Listen to the developers and
>>> fix what causes the most problems for them. 
>>> 
>>> You satisfy their needs and as a result have
>>> developers creating great apps easier and faster.
>>> 
>>> If you don't do this, then the focus from management
>>> is in the wrong place.
> 
>> But you're tilting at windmills here.
> 
> Cervantes... Don Quixote de la Mancha charging at
> what he thought was an evil, force and fraud initiating
> knight, but, in reality attacking a wind-mill.  That's 
> not the case, here.  (Why do so many people mis-apply
> that expression to deride others' efforts to improve
> things?)
> 
> These are actual design flaws and bugs, and lack of 
> clarity completeness and context in docs.
> 
>> This is not an official support channel. File Radars
> 
> I would but it's broken... again.  Hence:
>>> Javascript die.die.die
>>> Javascript die.die.die
> 
> On the plus side, display manufacturers have made
> larger, higher res displays.  Yay.  OTOH, who can
> afford them in this approximately 13th year of the 
> Bush-Clinton-Bush-Obama economic depression.  raspberries.
> 
> OT3H, all past bug reports and requests for improvements
> in docs have gone to the bit bucket.  Not corrected,
> just closed, rarely acknowledged.
> 
> I used to do tech support.  I've worked on ticketing/
> bug report systems.  I've seen developers and tech writers
> do such things in the past.  The only real solution is
> for someone within the company to be given enough clout
> to see that the bugs are actually corrected before the
> ticket gets closed.  The usual pattern is for it to get
> worse and worse over a period of a decade or more before
> someone comes along to clean house.
> 
> But I don't expect miracles.  Apple has high revenues,
> so some folks are satisfied with what they're getting
> for now, and I get the impression there are lots of 
> newbie developers willing to put up with draconian 
> nonsense just to have the chance to develop at all.
> 
> Until the bugs and design flaws and docs are all corrected, 
> I'll continue grumping by whatever channels are open, 
> thankyouverymuch, though I do refrain for long periods --
> often years at a stretch -- so as not to jam the lines 
> of communication.  I'm making an exception, this time,
> by posting twice, simply because there's quite a bit of
> spill-over aggravation from the US (and UK) politicians 
> of several parties striving mightily to make STEM job 
> markets worse in this political cycle.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
> 
> This email sent to sc...@cocoadoc.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Jeffrey Oleander]

> From: davel...@mac.com 
> To: cocoa-dev@lists.apple.com
> Date: Thursday, 2012 August 30, 18:26
>> On 2012 Aug 30, at 18:09, z...@mac.com wrote:
>>> From: Jeffrey Oleander 
>>> Thu, 2012 Aug 30 13:57:44 
>>> To: 
>>> Subject: Re: Sandboxing die.die.die 
>>> Sandboxing die.die.die
>>> Code-Signing die.die.die
>>> Javascript die.die.die
>>> Kludgey CPUs die.die.die
>>> Bodyshopping die.die.die
Contextless docs die.die.die
>>> (throwing hammer at hare-brained power-mad forces of
>>> evil)
>>> 
>>> Now, when can we cut the chains and get back to
>>> developing great apps?

>> Easy. When the exact items that we have issues with
>> are addressed.
>> 
>> It's not that hard. Listen to the developers and
>> fix what causes the most problems for them. 
>> 
>> You satisfy their needs and as a result have
>> developers creating great apps easier and faster.
>> 
>> If you don't do this, then the focus from management
>> is in the wrong place.

> But you're tilting at windmills here.

Cervantes... Don Quixote de la Mancha charging at
what he thought was an evil, force and fraud initiating
knight, but, in reality attacking a wind-mill.  That's 
not the case, here.  (Why do so many people mis-apply
that expression to deride others' efforts to improve
things?)

These are actual design flaws and bugs, and lack of 
clarity completeness and context in docs.

> This is not an official support channel. File Radars

I would but it's broken... again.  Hence:
>> Javascript die.die.die
>> Javascript die.die.die

On the plus side, display manufacturers have made
larger, higher res displays.  Yay.  OTOH, who can
afford them in this approximately 13th year of the 
Bush-Clinton-Bush-Obama economic depression.  raspberries.

OT3H, all past bug reports and requests for improvements
in docs have gone to the bit bucket.  Not corrected,
just closed, rarely acknowledged.

I used to do tech support.  I've worked on ticketing/
bug report systems.  I've seen developers and tech writers
do such things in the past.  The only real solution is
for someone within the company to be given enough clout
to see that the bugs are actually corrected before the
ticket gets closed.  The usual pattern is for it to get
worse and worse over a period of a decade or more before
someone comes along to clean house.

But I don't expect miracles.  Apple has high revenues,
so some folks are satisfied with what they're getting
for now, and I get the impression there are lots of 
newbie developers willing to put up with draconian 
nonsense just to have the chance to develop at all.

Until the bugs and design flaws and docs are all corrected, 
I'll continue grumping by whatever channels are open, 
thankyouverymuch, though I do refrain for long periods --
often years at a stretch -- so as not to jam the lines 
of communication.  I'm making an exception, this time,
by posting twice, simply because there's quite a bit of
spill-over aggravation from the US (and UK) politicians 
of several parties striving mightily to make STEM job 
markets worse in this political cycle.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[davelist]

But you're tilting at windmills here. This is not an official support channel. 
File Radars. And yes, we've had enough arguing about the effectiveness of doing 
that. You've spent far more time here and on the Xcode list complaining about 
losing fractions of a seconds waiting for animations to complete, etc. The time 
you lost there is minuscule in comparison to the time you've spent complaining 
about the issues on these mailing lists which does no good.

And many of us lose more than those fractions of a second hitting delete every 
time we see that one of your messages is just a rant.

Dave


On Aug 30, 2012, at 6:09 PM, z...@mac.com wrote:

> Easy. When the exact items that we have issues with are addressed.
> 
> It's not that hard. Listen to the developers and fix what causes the most 
> problems for them. 
> 
> You satisfy their needs and as a result have developers creating great apps 
> easier and faster.
> 
> If you don't do this, then the focus from management is in the wrong place.
> 
> 
> Sent from my Verizon Wireless BlackBerry
> 
> -Original Message-
> From: Jeffrey Oleander 
> Sender: cocoa-dev-bounces+zav=mac.com@lists.apple.comDate: Thu, 30 Aug 2012 
> 13:57:44 
> To: 
> Subject: Re: Sandboxing die.die.die
> 
> Sandboxing die.die.die
> Code-Signing die.die.die
> Javascript die.die.die
> Kludgey CPUs die.die.die
> Bodyshopping die.die.die
> (throwing hammer at hare-brained power-mad forces of evil)
> 
> Now, when can we cut the chains and get back to developing great apps?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[zav]

Easy. When the exact items that we have issues with are addressed.

It's not that hard. Listen to the developers and fix what causes the most 
problems for them. 

You satisfy their needs and as a result have developers creating great apps 
easier and faster.

If you don't do this, then the focus from management is in the wrong place.


Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Jeffrey Oleander 
Sender: cocoa-dev-bounces+zav=mac.com@lists.apple.comDate: Thu, 30 Aug 2012 
13:57:44 
To: 
Subject: Re: Sandboxing die.die.die

Sandboxing die.die.die
Code-Signing die.die.die
Javascript die.die.die
Kludgey CPUs die.die.die
Bodyshopping die.die.die
(throwing hammer at hare-brained power-mad forces of evil)

Now, when can we cut the chains and get back to developing great apps?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com

This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Jeffrey Oleander]

Sandboxing die.die.die
Code-Signing die.die.die
Javascript die.die.die
Kludgey CPUs die.die.die
Bodyshopping die.die.die
(throwing hammer at hare-brained power-mad forces of evil)

Now, when can we cut the chains and get back to developing great apps?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Stephane Sudre]

On Thu, Aug 30, 2012 at 1:59 AM, Greg Parker  wrote:
...
> OS X does not require sandboxing. For apps that are not sandboxed, 
> traditional file access is unchanged. Mountain Lion's Gatekeeper can be 
> configured to require signed apps, but it does not enforce sandboxing.

Somehow, Gatekeeper can be configured to require sandboxed apps (and
only some of them actually).

When the option to only accept applications from the Mac App Store is
on, this somehow implies that the applications will (*) be sandboxed
(since they are to be sandboxed to be submitted to the Mac App Store).



(*) at the time of this writing, insert a "probably" since previously
non-sandboxed apps are still available through the Mac App Store.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Mike Abdullah]

On 30 Aug 2012, at 05:10, John Bishop  wrote:

> On 30 Aug 2012 07:01:04 +0800, Roland King  wrote:
> 
>> 
>> On 30 Aug, 2012, at 6:34 AM, Alex Zavatone  wrote:
>> 
>>> But before anyone reads too far, I am making certain assumptions that may 
>>> indeed be false.  That iOS and Mac OS app Sandboxing is absolutely required 
>>> and you can't make apps without it enabled, whether the apps are destined 
>>> for the App store or not.
>>> 
>> 
>> For iOS it's true, always has been. For OSX it's not. If the app is for the 
>> store you must sandbox it, but you can distribute apps outside the store 
>> with no sandboxing at all and you have the intermediate step of signing with 
>> a developer id which doesn't require sandboxing but lets the user know apple 
>> knows who wrote the app. Use of iCloud on OSX requires the sandbox. 
> 
> Almost.  I believe use of iCloud is limited to apps from the Mac App Store, 
> which must be sandboxed whether including iCloud capabilities or not.  
> Sandboxing can be implemented outside the Mac App Store, but is rarely 
> (ever?) implemented because of the uh... "complexities" associated with the 
> technology at the moment. Those apps, sandboxed but delivered outside the Mac 
> App Store, which invoke iCloud APIs are reported to fail in the sandbox 
> because they don't include Apple's credentials in their code signature.
> 
> My personal opinion is that this restriction may eventually be relaxed by 
> Apple some day (don't hold your breath) if it becomes technically and 
> economically beneficial to do so simply by removing the Apple code signing 
> requirement in the OS.  I have no knowledge of plans or methods to accomplish 
> this... just a hunch.

You have filed a radar requesting this, yes?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[John Bishop]

On 30 Aug 2012 07:01:04 +0800, Roland King  wrote:

> 
> On 30 Aug, 2012, at 6:34 AM, Alex Zavatone  wrote:
> 
>> But before anyone reads too far, I am making certain assumptions that may 
>> indeed be false.  That iOS and Mac OS app Sandboxing is absolutely required 
>> and you can't make apps without it enabled, whether the apps are destined 
>> for the App store or not.
>> 
> 
> For iOS it's true, always has been. For OSX it's not. If the app is for the 
> store you must sandbox it, but you can distribute apps outside the store with 
> no sandboxing at all and you have the intermediate step of signing with a 
> developer id which doesn't require sandboxing but lets the user know apple 
> knows who wrote the app. Use of iCloud on OSX requires the sandbox. 

Almost.  I believe use of iCloud is limited to apps from the Mac App Store, 
which must be sandboxed whether including iCloud capabilities or not.  
Sandboxing can be implemented outside the Mac App Store, but is rarely (ever?) 
implemented because of the uh... "complexities" associated with the technology 
at the moment. Those apps, sandboxed but delivered outside the Mac App Store, 
which invoke iCloud APIs are reported to fail in the sandbox because they don't 
include Apple's credentials in their code signature.

My personal opinion is that this restriction may eventually be relaxed by Apple 
some day (don't hold your breath) if it becomes technically and economically 
beneficial to do so simply by removing the Apple code signing requirement in 
the OS.  I have no knowledge of plans or methods to accomplish this... just a 
hunch.

There ARE developers investigating sandboxing outside the Mac App Store.  I'm 
just not one of them.  We're using Dropbox application interfaces in lieu of 
iCloud outside of the Mac App Store.

--
John Bishop
Mulligan Software


Twitter:  MulliganGolf


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Greg Parker]

On Aug 29, 2012, at 3:34 PM, Alex Zavatone  wrote:
> But before anyone reads too far, I am making certain assumptions that may 
> indeed be false.  That iOS and Mac OS app Sandboxing is absolutely required 
> and you can't make apps without it enabled, whether the apps are destined for 
> the App store or not.
> 
> If my assumption is incorrect and Sandboxing is not required for non App 
> Store apps, (Mac OS or iOS) please let me know.  If that is the case, then 
> the trick is finding the documentation for file access without the Sandboxing 
> restrictions.

App signing and app sandboxing are two different things. 

A signed app includes a cryptographic claim of its author's identity.

A sandboxed app has additional restrictions enforced by the OS.

Sandboxed apps are signed, but signed apps are not necessarily sandboxed.

The App Stores require sandboxing. iOS also requires sandboxing for all apps, 
whether or not they are distributed by an App Store.

OS X does not require sandboxing. For apps that are not sandboxed, traditional 
file access is unchanged. Mountain Lion's Gatekeeper can be configured to 
require signed apps, but it does not enforce sandboxing.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

A digression (was Re: Sandboxing die.die.die)

[Andrei Freeman]

Sent from my iPad

On Aug 25, 2012, at 10:02 PM, Graham Cox  wrote:

> Well.
> 
> This code was based on a very old version ..., probably from 2008 or 9. 

Did you really just call something 'very old' from 2008 under a subject line 
that includes
".die.die.die?"

Sorry. Carry on.
-Andrei

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Roland King]

On 30 Aug, 2012, at 6:34 AM, Alex Zavatone  wrote:

> But before anyone reads too far, I am making certain assumptions that may 
> indeed be false.  That iOS and Mac OS app Sandboxing is absolutely required 
> and you can't make apps without it enabled, whether the apps are destined for 
> the App store or not.
> 

For iOS it's true, always has been. For OSX it's not. If the app is for the 
store you must sandbox it, but you can distribute apps outside the store with 
no sandboxing at all and you have the intermediate step of signing with a 
developer id which doesn't require sandboxing but lets the user know apple 
knows who wrote the app. Use of iCloud on OSX requires the sandbox. 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Zavatone]

On Aug 29, 2012, at 12:17 PM, Mike Abdullah wrote:

> 
> On 26 Aug 2012, at 03:02, Graham Cox  wrote:
> 
>> 
>> On 25/08/2012, at 8:14 PM, Mike Abdullah  wrote:
>> 
>>> I had a funny feeling you were going to point the finger at us ;-)
>>> Checked out the code, and I can assure you, iMedia is doing this:
>>> 
>>> NSURL* url = [NSURL URLWithString:library];
>>> NSString* path = [url path];
>>> 
>>> Where library is a string retrieved from the prefs to note where a media 
>>> library lives. I continue to be pretty sure no path-based APIs accept URL 
>>> strings.
>> 
>> 
>> Well.
>> 
>> This code was based on a very old version of the iMedia code, probably from 
>> 2008 or 9. It was certainly heavily modified when I adapted it to my own 
>> structures, but this part I kept intact. In fact, it still retains remnants 
>> of a workaround for some other Cocoa bug along with the comments pertaining 
>> to it, which is why I know I never altered it. Perhaps the behaviour just 
>> happened to work... or perhaps back then Apple were not storing a URL in the 
>> prefs but a path?
> 
> The latter seems more likely. The thing is this:
> 
> file://localhost/example.png
> 
> is a perfectly valid relative path, going:
> 
> file/ >   localhost   >   example.png
> 
> (if you were browsing in the Finder)
>> 
>> It's very probable that it got changed later - I haven't checked to see what 
>> the current version does. Presumably, it was updated to use NSURL at some 
>> point, but the version I used was path-based.
>> 
>> I hadn't realised that you were associated with Karelia. I wasn't pointing 
>> the finger, just trying to understand what the issue was. I accept that in 
>> porting the code Karelia no longer have any responsibility for it. What have 
>> been your experiences with sandboxing the iMedia browser?
> 
> No worries; the "finger-pointing" was meant mostly in jest. We're getting 
> there on sandboxing it. Mostly not to painful, but held up by a bookmarks 
> bug at present.


Actually, people over on the AppleScript list are already running into "this 
script is signed by an unknown developer", or apps based on AppleScript are 
simply crashing if the Mountain Lion security settings are set to only run apps 
from the App Store.

But before anyone reads too far, I am making certain assumptions that may 
indeed be false.  That iOS and Mac OS app Sandboxing is absolutely required and 
you can't make apps without it enabled, whether the apps are destined for the 
App store or not.

If my assumption is incorrect and Sandboxing is not required for non App Store 
apps, (Mac OS or iOS) please let me know.  If that is the case, then the trick 
is finding the documentation for file access without the Sandboxing 
restrictions.

But Mike, maybe you can answer a question for me.  Why must Sandboxing's access 
to the file system be locked down to be within an app and document type folders 
- on iOS and on the Mac?  Why can't we write preferences where every Mac app 
has written them before and limit writing to just the contents of a folder that 
matches the app's bundle?  

Instead of forbidding access to all but the approved folders and to folders 
inside the app, why not just lock the app's access based on file and folder 
permissions like we already have, and by restricting access to:

user:
- The preferences folder for the current app bundie ID: 
/User/currentUser/Library/Preferences/ + preference folders that are not its 
own within the current user folder/domain + app bundle ID
- Any folder within a folder in the user's Library folder +  the app bundle ID 
folder:   /User/currentUser/Library/*/anyFolderName/ + folder with the app 
bundle ID

root:
- root/Library
- root/System
- those other unix folders off of root 

How does "every app is an island" make the system more secure and the user 
experience and the developer experience better by restricting access to only 
the app's content folders, the music, documents, addresses and so on?

How does preventing an application (code signed or not) from writing to the 
/Users/currentUser/Library in a sub folder reserved for the app actually help 
make a better experience?  And if you want to write an app with an Enterprise 
or Personal license and will never distribute the app over the App Store, why 
can we not bypass this restriction? What's worse, as this gets promoted, 
documentation for how to write and read files to the file system gets harder to 
find.  Additionally, execs in companies who will have to support Macs and iOS 
devices on Enterprise level will declare that for security reasons the 
Gatekeeper restriction on Macs must be locked in the "Only allow apps from the 
App Store".

Why I care about this.
In the past, I've created a serialized app that is an automated suite of Xcode 
wrapped AppleScripts and OC classes that talk between 5 apps and write files 
into folders at the root, so that the files are purposely independent of 
whichever us

Re: Sandboxing die.die.die

[Mike Abdullah]

On 26 Aug 2012, at 03:02, Graham Cox  wrote:

> 
> On 25/08/2012, at 8:14 PM, Mike Abdullah  wrote:
> 
>> I had a funny feeling you were going to point the finger at us ;-)
>> Checked out the code, and I can assure you, iMedia is doing this:
>> 
>> NSURL* url = [NSURL URLWithString:library];
>> NSString* path = [url path];
>> 
>> Where library is a string retrieved from the prefs to note where a media 
>> library lives. I continue to be pretty sure no path-based APIs accept URL 
>> strings.
> 
> 
> Well.
> 
> This code was based on a very old version of the iMedia code, probably from 
> 2008 or 9. It was certainly heavily modified when I adapted it to my own 
> structures, but this part I kept intact. In fact, it still retains remnants 
> of a workaround for some other Cocoa bug along with the comments pertaining 
> to it, which is why I know I never altered it. Perhaps the behaviour just 
> happened to work... or perhaps back then Apple were not storing a URL in the 
> prefs but a path?

The latter seems more likely. The thing is this:

file://localhost/example.png

is a perfectly valid relative path, going:

file/   >   localhost   >   example.png

(if you were browsing in the Finder)
> 
> It's very probable that it got changed later - I haven't checked to see what 
> the current version does. Presumably, it was updated to use NSURL at some 
> point, but the version I used was path-based.
> 
> I hadn't realised that you were associated with Karelia. I wasn't pointing 
> the finger, just trying to understand what the issue was. I accept that in 
> porting the code Karelia no longer have any responsibility for it. What have 
> been your experiences with sandboxing the iMedia browser?

No worries; the "finger-pointing" was meant mostly in jest. We're getting there 
on sandboxing it. Mostly not to painful, but held up by a bookmarks bug at 
present.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 25/08/2012, at 8:14 PM, Mike Abdullah  wrote:

> I had a funny feeling you were going to point the finger at us ;-)
> Checked out the code, and I can assure you, iMedia is doing this:
> 
> NSURL* url = [NSURL URLWithString:library];
> NSString* path = [url path];
> 
> Where library is a string retrieved from the prefs to note where a media 
> library lives. I continue to be pretty sure no path-based APIs accept URL 
> strings.


Well.

This code was based on a very old version of the iMedia code, probably from 
2008 or 9. It was certainly heavily modified when I adapted it to my own 
structures, but this part I kept intact. In fact, it still retains remnants of 
a workaround for some other Cocoa bug along with the comments pertaining to it, 
which is why I know I never altered it. Perhaps the behaviour just happened to 
work... or perhaps back then Apple were not storing a URL in the prefs but a 
path?

It's very probable that it got changed later - I haven't checked to see what 
the current version does. Presumably, it was updated to use NSURL at some 
point, but the version I used was path-based.

I hadn't realised that you were associated with Karelia. I wasn't pointing the 
finger, just trying to understand what the issue was. I accept that in porting 
the code Karelia no longer have any responsibility for it. What have been your 
experiences with sandboxing the iMedia browser?


--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Mike Abdullah]

On 25 Aug 2012, at 09:09, Graham Cox  wrote:

> 
> On 24/08/2012, at 10:35 PM, Mike Abdullah  wrote:
> 
>> I’m surprised by this. The path-based APIs were seriously handling a path 
>> beginning with file:// in the way that you expect?
> 
> Apparently so. This code was originally derived from Karelia's iMedia browser 
> and I never had reason to look at it in detail until just now.

I had a funny feeling you were going to point the finger at us ;-)
Checked out the code, and I can assure you, iMedia is doing this:

NSURL* url = [NSURL URLWithString:library];
NSString* path = [url path];

Where library is a string retrieved from the prefs to note where a media 
library lives. I continue to be pretty sure no path-based APIs accept URL 
strings.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 24/08/2012, at 10:35 PM, Mike Abdullah  wrote:

> I’m surprised by this. The path-based APIs were seriously handling a path 
> beginning with file:// in the way that you expect?

Apparently so. This code was originally derived from Karelia's iMedia browser 
and I never had reason to look at it in detail until just now.


> What were you handing this “path” off to? +[NSDictionary 
> dictionaryWithContentsOfFile:] ?

Yes.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Mike Abdullah]

On 24 Aug 2012, at 00:33, Graham Cox wrote:

> 
> On 24/08/2012, at 3:11 AM, Greg Parker  wrote:
> 
>> On Aug 22, 2012, at 7:14 PM, Graham Cox  wrote:
>>> Turns out the problem I was having with this is because of the behaviour of 
>>> [NSURL fileURLWithPath:isDirectory:].
>>> 
>>> When I passed the path to the iPhoto database file (~/Pictures/iPhoto 
>>> Library/Album.xml) the resulting URL was bizarrely altered to point to some 
>>> non-existent path within my sandbox. In fact it looks like a bug because it 
>>> ended up concatenating 'file://' somewhere in the middle of the path which 
>>> makes no sense.
>> 
>> From the +fileURLWithPath:isDirectory: documentation:
>> "If path begins with a tilde, it must first be expanded with 
>> stringByExpandingTildeInPath."
>> 
>> Note also that paths with '~' in them are treated differently in sandboxed 
>> apps.
> 
> In fact the string doesn't contain a tilde. I think in summarising my issue I 
> glossed over the exact situation, which is that I have a string which is 
> "file://localhost/Users//Pictures/iPhoto Library/Album.xml". This string 
> is extracted from the preferences of com.apple.iApps plist as being the path 
> to the current iPhoto database.
> 
> In my old code, which used NSString path processing methods, everything 
> worked fine even though the string is prefixed with "file://". The presence 
> of this prefix didn't cause any issues with accessing the file using 
> path-based APIs. Because of that I was not really aware that it was a URL 
> rather than just a path until I tried to update my code to use NSURLs.

I’m surprised by this. The path-based APIs were seriously handling a path 
beginning with file:// in the way that you expect? What were you handing this 
“path” off to? +[NSDictionary dictionaryWithContentsOfFile:] ?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 24/08/2012, at 10:47 AM, Kyle Sluder  wrote:

> You're using it correctly, but I'm suggesting that the better approach would 
> not use it at all. Rather than constructing a URL string and creating an 
> NSURL out of it, it's better to create a file path and create an NSURL with 
> +fileURLWithPath::. It seems to be causing you issues, but it is the more 
> correct approach.


OK, gotcha.

Well, I don't have a lot of choice, that's how the URL is stored in the iApps 
preferences by iPhoto. Since there's no media access APIs, we are at the mercy 
of these implementation details that Apple have used.

I expect that once Apple sandbox these apps (assuming they ever do) our code 
will break again and have to be revved.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Kyle Sluder]

On Aug 23, 2012, at 5:41 PM, Graham Cox  wrote:

> 
> Hang on, given the above string (which as far as I can tell is a 'proper' URL 
> and not just a path), +URLWithString works fine and 
> +fileURLWithPath:isDirectory makes a complete hash of it.

Well, I was operating under the assumption that you actually provided us with 
the string you were using, not a percent-unencoded variant thereof. Details 
matter.

> 
> What is +URLWithString: for, if not this?

You're using it correctly, but I'm suggesting that the better approach would 
not use it at all. Rather than constructing a URL string and creating an NSURL 
out of it, it's better to create a file path and create an NSURL with 
+fileURLWithPath::. It seems to be causing you issues, but it is the more 
correct approach.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 24/08/2012, at 10:11 AM, Kyle Sluder  wrote:

> Just FYI, this is not a valid URL. The space in "iPhoto Library" needs
> to be percent-encoded.

It is, in fact. I retyped it in Mail.

>> So I think I'm correct to be using [NSURL URLWithString:] here (tell me
>> if that's not right!) and that does point to the right file and
>> everything is now working.
> 
> In general, no. You should not use +URLWithString: to create an NSURL
> from a filesystem path. Use +fileURLWithPath:isDirectory: instead. It
> handles cases like percent-encoding.

Hang on, given the above string (which as far as I can tell is a 'proper' URL 
and not just a path), +URLWithString works fine and 
+fileURLWithPath:isDirectory makes a complete hash of it.

What is +URLWithString: for, if not this?

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Kyle Sluder]

On Thu, Aug 23, 2012, at 04:33 PM, Graham Cox wrote:
> In fact the string doesn't contain a tilde. I think in summarising my
> issue I glossed over the exact situation, which is that I have a string
> which is "file://localhost/Users//Pictures/iPhoto Library/Album.xml".

Just FYI, this is not a valid URL. The space in "iPhoto Library" needs
to be percent-encoded.

> This string is extracted from the preferences of com.apple.iApps plist as
> being the path to the current iPhoto database.
> 
> In my old code, which used NSString path processing methods, everything
> worked fine even though the string is prefixed with "file://". The
> presence of this prefix didn't cause any issues with accessing the file
> using path-based APIs. Because of that I was not really aware that it was
> a URL rather than just a path until I tried to update my code to use
> NSURLs.
> 
> In updating the code to use NSURLs, passing this string to [NSURL
> fileURLWithPath:isDirectory:] gave me an unexpected result. Now I
> understand the full range of behaviour of that method, it makes a lot
> more sense, though I'm not entirely sure that the resulting URL (which
> certainly did not point to the right file) could ever be valid, because
> the "file://" prefix ends up in the middle of the resulting path. It's
> being treated as a relative URL (which it isn't). OK, I accept Mike's
> argument that there *could* be a folder called "file:", or at least that
> would be legal in terms of general URLs, though not in terms of the Mac
> File System which I believe forbids colons for legacy reasons, though I
> doubt that NSURL bothers to take that into consideration.

Colons are legal characters in filenames. The Finder converts them to
slashes for display. (Though I wonder if the underlying HFS filesystem
plugin converts them *back* into colons for storage in the directory
tables.)

> 
> So I think I'm correct to be using [NSURL URLWithString:] here (tell me
> if that's not right!) and that does point to the right file and
> everything is now working.

In general, no. You should not use +URLWithString: to create an NSURL
from a filesystem path. Use +fileURLWithPath:isDirectory: instead. It
handles cases like percent-encoding.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 24/08/2012, at 3:11 AM, Greg Parker  wrote:

> On Aug 22, 2012, at 7:14 PM, Graham Cox  wrote:
>> Turns out the problem I was having with this is because of the behaviour of 
>> [NSURL fileURLWithPath:isDirectory:].
>> 
>> When I passed the path to the iPhoto database file (~/Pictures/iPhoto 
>> Library/Album.xml) the resulting URL was bizarrely altered to point to some 
>> non-existent path within my sandbox. In fact it looks like a bug because it 
>> ended up concatenating 'file://' somewhere in the middle of the path which 
>> makes no sense.
> 
> From the +fileURLWithPath:isDirectory: documentation:
> "If path begins with a tilde, it must first be expanded with 
> stringByExpandingTildeInPath."
> 
> Note also that paths with '~' in them are treated differently in sandboxed 
> apps.

In fact the string doesn't contain a tilde. I think in summarising my issue I 
glossed over the exact situation, which is that I have a string which is 
"file://localhost/Users//Pictures/iPhoto Library/Album.xml". This string is 
extracted from the preferences of com.apple.iApps plist as being the path to 
the current iPhoto database.

In my old code, which used NSString path processing methods, everything worked 
fine even though the string is prefixed with "file://". The presence of this 
prefix didn't cause any issues with accessing the file using path-based APIs. 
Because of that I was not really aware that it was a URL rather than just a 
path until I tried to update my code to use NSURLs.

In updating the code to use NSURLs, passing this string to [NSURL 
fileURLWithPath:isDirectory:] gave me an unexpected result. Now I understand 
the full range of behaviour of that method, it makes a lot more sense, though 
I'm not entirely sure that the resulting URL (which certainly did not point to 
the right file) could ever be valid, because the "file://" prefix ends up in 
the middle of the resulting path. It's being treated as a relative URL (which 
it isn't). OK, I accept Mike's argument that there *could* be a folder called 
"file:", or at least that would be legal in terms of general URLs, though not 
in terms of the Mac File System which I believe forbids colons for legacy 
reasons, though I doubt that NSURL bothers to take that into consideration.

So I think I'm correct to be using [NSURL URLWithString:] here (tell me if 
that's not right!) and that does point to the right file and everything is now 
working.

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Mike Abdullah]

On 23 Aug 2012, at 18:11, Greg Parker wrote:

> On Aug 22, 2012, at 7:14 PM, Graham Cox  wrote:
>> Turns out the problem I was having with this is because of the behaviour of 
>> [NSURL fileURLWithPath:isDirectory:].
>> 
>> When I passed the path to the iPhoto database file (~/Pictures/iPhoto 
>> Library/Album.xml) the resulting URL was bizarrely altered to point to some 
>> non-existent path within my sandbox. In fact it looks like a bug because it 
>> ended up concatenating 'file://' somewhere in the middle of the path which 
>> makes no sense.
> 
> From the +fileURLWithPath:isDirectory: documentation:
> "If path begins with a tilde, it must first be expanded with 
> stringByExpandingTildeInPath."
> 
> Note also that paths with '~' in them are treated differently in sandboxed 
> apps.
> 
> 
>> Instead, I used [NSURL URLWithString:] and it works correctly.
> 
> Don't do that. +URLWithString: expects a string that represents a URL, not a 
> string that represents a filesystem path.

It seems that he does actually have a URL string to start with, rather than a 
path.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Greg Parker]

On Aug 22, 2012, at 7:14 PM, Graham Cox  wrote:
> Turns out the problem I was having with this is because of the behaviour of 
> [NSURL fileURLWithPath:isDirectory:].
> 
> When I passed the path to the iPhoto database file (~/Pictures/iPhoto 
> Library/Album.xml) the resulting URL was bizarrely altered to point to some 
> non-existent path within my sandbox. In fact it looks like a bug because it 
> ended up concatenating 'file://' somewhere in the middle of the path which 
> makes no sense.

>From the +fileURLWithPath:isDirectory: documentation:
"If path begins with a tilde, it must first be expanded with 
stringByExpandingTildeInPath."

Note also that paths with '~' in them are treated differently in sandboxed apps.


> Instead, I used [NSURL URLWithString:] and it works correctly.

Don't do that. +URLWithString: expects a string that represents a URL, not a 
string that represents a filesystem path.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Mike Abdullah]

On 23 Aug 2012, at 11:52, Graham Cox wrote:

> 
> On 23/08/2012, at 6:48 PM, Mike Abdullah  wrote:
> 
>> Your description here sounds unlikely. The URL APIs are extremely 
>> well-tested and robust; I would be surprised if you really have found a bug 
>> like this.
>> 
>> What is the path you were sending into +fileURLWith… ? Your description 
>> suggests it contains a ~ symbol, which NSURL is not going to resolve for 
>> you. If +URLWithString: is working instead, then most likely you never had a 
>> path to start with, but a string representation of a URL.
>> 
>> Where did this path even originate from, considering all the relevant APIs 
>> use URLs these days?
> 
> Yes, it's a string representation of a URL, so using URLWithString is right 
> here. (it's file://localhost/.)
> 
> The reason I didn't try this at first is because I was updating code based on 
> paths, not URLs, and formerly this string was treated as a full path using 
> the NSString paths APIs and other things that used them, such as 
> NSFileManager. None of these APIs seemed to mind about the file:// and I 
> wasn't even aware it was there, the path coming from the iApps preferences 
> file and passed along to other objects based on paths.

What do you mean by “mind”? Any string is a valid path, so no path-based API is 
ever going to complain about the path you giving it being invalid; only that 
nothing happens to exist at that path.
> 
> When you pass this to [URLWithFile:isDirectory:], it does end up as a 
> malformed URL which looks like /file:// rest of the above path>.

I don’t see that as an invalid URL. I assume you’ve missed out the initial 
file:// bit in your description. The +fileURLWithPath… methods are documented 
as handling a relative path as being relative to the home directory. It sees 
that the “path” you’re giving it doesn’t start with a slash, and so presumes 
it’s relative, tacking it onto the end of the home directory. (for a sandboxed 
app the home directory is your container)
> 
> I guess this counts as "undefined behaviour" rather than trying to make the 
> best of a programmer error, which is probably fair enough. S... is it a 
> bug? Not really, though NSURL *could* make a better stab of dealing with it 
> than it does.

I don’t see how it could. Any path is technically valid. Yes, NSURL could spot 
that the string is also a valid file URL in its own right, but that’s only an 
educated guess. It’s always possible that you really are dealing with a folder 
named “file:” and if the API were to throw an exception that would break the 
app. If it logged a warning, that could be helpful, but also wasteful.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 23/08/2012, at 6:48 PM, Mike Abdullah  wrote:

> Your description here sounds unlikely. The URL APIs are extremely well-tested 
> and robust; I would be surprised if you really have found a bug like this.
> 
> What is the path you were sending into +fileURLWith… ? Your description 
> suggests it contains a ~ symbol, which NSURL is not going to resolve for you. 
> If +URLWithString: is working instead, then most likely you never had a path 
> to start with, but a string representation of a URL.
> 
> Where did this path even originate from, considering all the relevant APIs 
> use URLs these days?

Yes, it's a string representation of a URL, so using URLWithString is right 
here. (it's file://localhost/.)

The reason I didn't try this at first is because I was updating code based on 
paths, not URLs, and formerly this string was treated as a full path using the 
NSString paths APIs and other things that used them, such as NSFileManager. 
None of these APIs seemed to mind about the file:// and I wasn't even aware it 
was there, the path coming from the iApps preferences file and passed along to 
other objects based on paths.

When you pass this to [URLWithFile:isDirectory:], it does end up as a malformed 
URL which looks like /file://.

I guess this counts as "undefined behaviour" rather than trying to make the 
best of a programmer error, which is probably fair enough. S... is it a 
bug? Not really, though NSURL *could* make a better stab of dealing with it 
than it does.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Mike Abdullah]

On 23 Aug 2012, at 03:14, Graham Cox wrote:

> 
> On 23/08/2012, at 9:37 AM, Graham Cox  wrote:
> 
>> Trying to work around this is proving impossible with the current sandbox 
>> implementation - there are too many opaque hacks in the system that mean you 
>> cannot trust the URLs you get from anywhere to actually point to the right 
>> place, and you also have to hard-code paths in your entitlements which are 
>> extremely fragile under both localisation and system updates. (For example, 
>> if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that 
>> location changes, or is named differently, my app stops working. Note the 
>> name of the iPhoto Library did subtly change between 10.7 and 10.8 - the 
>> space is a different unicode character now).
> 
> 
> 
> Well, I spoke too soon, and have actually solved this problem. Whether it 
> proves to be robust I can't say, but it wouldn't seem to be any worse than 
> our un-sandboxed app in that respect.
> 
> 
> Turns out the problem I was having with this is because of the behaviour of 
> [NSURL fileURLWithPath:isDirectory:].
> 
> When I passed the path to the iPhoto database file (~/Pictures/iPhoto 
> Library/Album.xml) the resulting URL was bizarrely altered to point to some 
> non-existent path within my sandbox. In fact it looks like a bug because it 
> ended up concatenating 'file://' somewhere in the middle of the path which 
> makes no sense. Instead, I used [NSURL URLWithString:] and it works correctly.

Your description here sounds unlikely. The URL APIs are extremely well-tested 
and robust; I would be surprised if you really have found a bug like this.

What is the path you were sending into +fileURLWith… ? Your description 
suggests it contains a ~ symbol, which NSURL is not going to resolve for you. 
If +URLWithString: is working instead, then most likely you never had a path to 
start with, but a string representation of a URL.

Where did this path even originate from, considering all the relevant APIs use 
URLs these days?

Of course I might be wrong and you’ve found a bug. If so I would like to be 
aware of it and file a radar on the subject.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Derek Chesterfield]

Gatekeeper uses the Quarantine mechanisms. Installer does not set the 
Quarantine flag, so the installed app does not trigger Gatekeeper. 

Basically if you have explicitly installed an app, you are expressing that you 
trust it. Or, expressed along the lines of the intent-driven model... I've 
installed this, I intend to execute it.  

On 23 Aug 2012, at 01:06, danchik  wrote:

> If the package is signed by Apple Developer's Installer certificate, gate 
> keeper does not complain (just askes to ok the installation) and then never 
> sais anything about the app that was installed (though it is NOT signed by 
> Apples Developer's Software certificate).
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Britt Durbrow]

On Aug 22, 2012, at 7:16 PM, Graham Cox  wrote:

> 
> On 23/08/2012, at 11:33 AM, Britt Durbrow 
>  wrote:
> 
>> there's no programatic way to tell the difference between the two
> 
> 
> Indeed, which is why you need to encourage the use of human intelligence 
> instead, which very often can tell when something is "fishy".
> 
> When a computer needs to do something truly intelligent, it's usually a good 
> idea to defer to the user.
> 
> --Graham

Which, unfortunately, leads us to the Dancing Pigs problem... 

http://en.wikipedia.org/wiki/Dancing_pigs
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 23/08/2012, at 11:33 AM, Britt Durbrow 
 wrote:

> there's no programatic way to tell the difference between the two


Indeed, which is why you need to encourage the use of human intelligence 
instead, which very often can tell when something is "fishy".

When a computer needs to do something truly intelligent, it's usually a good 
idea to defer to the user.

--Graham
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 23/08/2012, at 9:37 AM, Graham Cox  wrote:

> Trying to work around this is proving impossible with the current sandbox 
> implementation - there are too many opaque hacks in the system that mean you 
> cannot trust the URLs you get from anywhere to actually point to the right 
> place, and you also have to hard-code paths in your entitlements which are 
> extremely fragile under both localisation and system updates. (For example, 
> if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that 
> location changes, or is named differently, my app stops working. Note the 
> name of the iPhoto Library did subtly change between 10.7 and 10.8 - the 
> space is a different unicode character now).



Well, I spoke too soon, and have actually solved this problem. Whether it 
proves to be robust I can't say, but it wouldn't seem to be any worse than our 
un-sandboxed app in that respect.


Turns out the problem I was having with this is because of the behaviour of 
[NSURL fileURLWithPath:isDirectory:].

When I passed the path to the iPhoto database file (~/Pictures/iPhoto 
Library/Album.xml) the resulting URL was bizarrely altered to point to some 
non-existent path within my sandbox. In fact it looks like a bug because it 
ended up concatenating 'file://' somewhere in the middle of the path which 
makes no sense. Instead, I used [NSURL URLWithString:] and it works correctly.

I've also had to rev a fair bit of my code to work with URLs rather than paths, 
but that was a legacy from before URLs were more commonly used so that's not a 
sandboxing issue per se, but using URLs works with sandboxing whereas paths do 
not always it seems. I've been meaning to update this legacy code for a while, 
but while it continued to work had no real incentive to do it.

Because the iPhoto Library lives inside ~/Pictures, and there is a general 
entitlement for that folder, I no longer need a special temporary exception for 
the iPhoto Library, so the hard-coded paths issue goes away, as long as iPhoto 
Library remains in this location. I look up the actual name by peeking at iApps 
preferences and I still need a temporary entitlement for that, so I'm still at 
the mercy of Apple changes to these things, but no more so than before.

The other aspect to the general problem I was having, that of managing to 
resolve security-scoped bookmarks across sessions, I solved yesterday. Turns 
out the issue there is that you need to call the 
-startAccessingSecurityScopedResource after resolving the bookmark and leave it 
in that state until you are completely done with the folder (in my case that's 
only when the app quits).

I get an exception logged when dragging and dropping, but oddly it doesn't seem 
to cause any problems - D&D still works fine: Anyone any thoughts on this:

Artboard(70831) deny file-issue-extension /Users/grahamcox/Pictures/IMG_0899.JPG

OS Version:  Mac OS X 10.8 (12A269)
Report Version:  8

Thread 0:
0   libsystem_kernel.dylib  0x000103f99efe __mac_syscall + 10
1   libsystem_sandbox.dylib 0x00010401e4fe 
sandbox_issue_fs_rw_extension + 32
2   CoreFoundation  0x0001013b77e2 
__CFPasteboardIssueSandboxExtensionForPath + 130
3   CoreFoundation  0x0001013b74e6 
__CFPasteboardIssueSandboxExtensionForFileURL + 150
4   CoreFoundation  0x0001013838b7 
__CFPasteboardSetData + 1287
5   CoreFoundation  0x00010138333e CFPasteboardSetData 
+ 446
6   AppKit  0x000101bb774d -[NSPasteboard 
_setData:forType:index:usesPboardTypes:] + 376
7   AppKit  0x000101bb9020 -[NSPasteboard 
writeObjects:] + 1219
8   Artboard0x00010009b8f1 
-[GCMediaBrowserController imageBrowser:writeItemsAtIndexes:toPasteboard:] + 
161 (GCMediaBrowserController.m:636)
9   ImageKit0x00010a19a6b6 
-[IKImageBrowserView(ImageBrowserDragNDropInternal) 
startDragNDropWithEvent:itemIndexes:] + 616
10  ImageKit0x00010a19f949 
-[IKImageBrowserView(ImageBrowserEvents) mouseDragged:] + 1235


So unless any further issues are uncovered by testing with sandboxing, it looks 
like my app will now be able to adopt it with no loss of functionality, which 
is a huge relief.


I still think the general issues surrounding the sandboxing implementation are 
worth discussion though.


--Graham
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Britt Durbrow]

I don't think that it's physically possible to resolve this issue - basically, 
we're trying to have our cake (er, have our security) and eat it too (er, use 
the functionality of the app).

Consider a 'shoebox' app that doesn't deal with run-of-the-mill media (photos, 
movies, etc)... let's say it manages CAD/CAM files - something that Apple won't 
have an API for. And it integrates into your CAD/CAM programs via plugins, and 
an intranet/internet/cloud document sharing system. By definition, the only 
behavioral difference between this app and a cyber-espionage-enabled app is 
where the data gets sent: the good app sends it to 
MyAwesomeCloudCollaborationSite.com, the bad app also sends it to 
EvilHaxorsGonnaSpyOnYou.com... and there's no programatic way to tell the 
difference between the two.

Or perhaps a more widespread target: an app that manages receipts and credit 
card data, no matter where in the file system they end up (email, PDFs, MS 
Office documents, whatnot), and integrates with a cloud system for 
collaborating with accountants, banks, the IRS, etc... again, the only way a 
good app differs from a bad one is who is on the other end of the network 
socket.

Security is always at odds with ease-of-use and functionality; and while an 
insecure system can be useless due to the inability to trust it, an overly 
secure system will be also useless because the security measures prevent it 
from doing it's job... so by demanding total security (all MAS apps must be 
sandboxed); Apple has also rendered an entire class of apps nonfunctional. Part 
of the rationale that I've heard for the current set of sandboxing requirements 
is that it protects unsophisticated users... who, unfortunately, are the very 
users who would need a cross-app shoebox system the most.

(note: due to that 90% sales figure, for the purposes of this discussion, I am 
considering not selling thru the MAS to be a non-option for economic reasons; 
even though technically speaking, as of today an unsandboxed-but-signed app 
works OK on a default install of Mountain Lion)
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 23/08/2012, at 10:45 AM, Todd Heberlein  wrote:

>> Where life is made difficult is with more general access to the file system, 
>> which is a perfectly legitimate thing to do. A user stores various media all 
>> over the file system and there is no reason why an app shouldn't have access 
>> to it.
> 
> Except this is how cyber espionage works.
> 
> The "Pretty Girls" calendar application is a Trojan horse that, upon reaching 
> a certain date (i.e., after it is approved by Apple), starts reading your 
> Word/Pages document and exfiltrating them off the system.


Understood, but this is the problem with security in general - how to make 
something secure without inconveniencing legitimate use. It's a hard problem, 
look at how appalling airport "security" is for the 99.999% of legitimate 
users.

I'm not sure what the solution is, but I do feel that sandboxing as it has been 
implemented is a poor solution because it is inconveniencing legitimate use 
(and I mean use, not development, which is SERIOUSLY inconvenienced). Suddenly 
legitimate users who manage all their photos with iPhoto cannot quickly access 
those photos with our app because our app cannot access iPhoto's media. They 
are inconvenienced - they have to find some other way to get their photos into 
our app. It makes our app less useful than before.

I can't see how penalising these legitimate users to counter a hypothetical 
threat is striking the right balance.

Once "Pretty Girls" is detected for what it is, its certificate can be revoked 
and the problem gradually solves itself. If in the meantime the user had 
experienced data loss or damage then they should have known better than to 
trust the skanky app in the first place. Obviously that's not ideal but give me 
common sense over the Gulag any day. Note that because "Pretty Girls" got past 
Gatekeeper, they were probably MORE likely to trust it than if they had just 
exercised a sensible amount of caution in the first place. Gatekeeper is like 
the front door to your house, except automated to let anyone in who waves the 
right credentials at it. Then they're in your house. In real life I'd prefer to 
take a look at that person and decide for myself whether they can be trusted. I 
might get it wrong, but it was my decision. For social engineering attacks, 
like "Pretty Girls", the only solution is user education.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Yingshen Yu]

Besides, even if you use an installer, Mountain Lion is fine without app 
signed, however it still make sense to sign app to prevent your  app be 
modified by mal-ware or virus.

-Jonny


在 2012-8-23，上午8:06，danchik  写道：

> A somewhat related question.  It seems that the gatekeeper is mostly 
> concenrned with the signature on the installer package and not the software 
> it installed.  If the package is signed by Apple Developer's Installer 
> certificate, gate keeper does not complain (just askes to ok the 
> installation) and then never sais anything about the app that was installed 
> (though it is NOT signed by Apples Developer's Software certificate).
> 
> So is it important to sign the code as well and not just the package (from 
> the usability and end user experience point of view)?
> 
> 
> - Original Message - From: "Mike Abdullah" 
> To: "James Merkel" 
> Cc: 
> Sent: Wednesday, August 22, 2012 4:44 PM
> Subject: Re: Sandboxing die.die.die
> 
> 
>> 
>> On 22 Aug 2012, at 21:31, James Merkel wrote:
>> 
>>> 
>>> On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:
>>> 
>>>> On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
>>>>> Notification Center is usable by any app; I'm using it and App Store
>>>>> isn't even a possibility at this point.
>>>> 
>>>> I believe your app has to be code-signed. But any valid code signature
>>>> should work.
>>>> 
>>>> --Kyle Sluder
>>> 
>>> However, I don't think you can self sign it can you?
>> 
>> Yes you can. Apple recommend DeveloperID instead though these days. It’s 
>> $99, pretty easy. Just do it.
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/danchik%40rebelbase.com
>> 
>> This email sent to danc...@rebelbase.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/yingshen.yu%40gmail.com
> 
> This email sent to yingshen...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Yingshen Yu]

depends on what type of your installer is. 
For drag drop installation, you need sign the app.

-Jonny


在 2012-8-23，上午8:06，danchik  写道：

> A somewhat related question.  It seems that the gatekeeper is mostly 
> concenrned with the signature on the installer package and not the software 
> it installed.  If the package is signed by Apple Developer's Installer 
> certificate, gate keeper does not complain (just askes to ok the 
> installation) and then never sais anything about the app that was installed 
> (though it is NOT signed by Apples Developer's Software certificate).
> 
> So is it important to sign the code as well and not just the package (from 
> the usability and end user experience point of view)?
> 
> 
> - Original Message - From: "Mike Abdullah" 
> To: "James Merkel" 
> Cc: 
> Sent: Wednesday, August 22, 2012 4:44 PM
> Subject: Re: Sandboxing die.die.die
> 
> 
>> 
>> On 22 Aug 2012, at 21:31, James Merkel wrote:
>> 
>>> 
>>> On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:
>>> 
>>>> On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
>>>>> Notification Center is usable by any app; I'm using it and App Store
>>>>> isn't even a possibility at this point.
>>>> 
>>>> I believe your app has to be code-signed. But any valid code signature
>>>> should work.
>>>> 
>>>> --Kyle Sluder
>>> 
>>> However, I don't think you can self sign it can you?
>> 
>> Yes you can. Apple recommend DeveloperID instead though these days. It’s 
>> $99, pretty easy. Just do it.
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/danchik%40rebelbase.com
>> 
>> This email sent to danc...@rebelbase.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/yingshen.yu%40gmail.com
> 
> This email sent to yingshen...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Sean McBride]

On Thu, 23 Aug 2012 09:37:05 +1000, Graham Cox said:

>The only bright spot in all of this is the fact that on Mac at least you
>have a channel other than the App Store to deliver apps, but since the
>App Store is responsible for 90% of our sales, it would be commercial
>suicide to leave it. So we're stuck.

After reading your (well deserved) criticisms, I was going to say 'put your 
money where your mouth is', but I guess you can't.  :(  And that's telling.  
Apple knows they can get away with what they're doing.  Well, that's what 
happens when you lock yourself into a walled garden I guess. :(  It is a sad 
state of affairs, I agree.

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[koko]

On Aug 22, 2012, at 12:03 PM, Jayson Adams wrote:

> I'm wouldn't waste my time with third-party apps when there are lots of other 
> targets that come pre-installed on every single machine.

Here here.

We are dealing with the same issue as Graham and this is keeping one of our 
Apps out of the MAS for know.  I am anxiously awaiting Grahams's solution.

-koko

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Todd Heberlein]

On Aug 22, 2012, at 4:37 PM, Graham Cox  wrote:

> Where life is made difficult is with more general access to the file system, 
> which is a perfectly legitimate thing to do. A user stores various media all 
> over the file system and there is no reason why an app shouldn't have access 
> to it.

Except this is how cyber espionage works.

The "Pretty Girls" calendar application is a Trojan horse that, upon reaching a 
certain date (i.e., after it is approved by Apple), starts reading your 
Word/Pages document and exfiltrating them off the system.

Or the "Special Draw" application has a vulnerability, a user reads in a 
malicious document, and a command & control agent is dropped on your system.

I put together a little demo and video demonstrating this last example (it's 
actually a dig at the antivirus/security industry):

Glowing Embers: The Myth of the Nation State Requirement
http://www.netsq.com/Podcasts/Data/2012/GlowingEmbers/


Unfortunately, I too have problems with the Mac App Store restrictions, 
including no privilege escalation, but I do not have a good solution to 
recommend. :-\

Todd

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Zavatone]

On Aug 22, 2012, at 8:12 PM, Graham Cox wrote:

> 
> 
> On 23/08/2012, at 10:02 AM, Alex Zavatone  wrote:
> 
>> Since the preferences folder lives in the app, the preferences are deleted 
>> when the app is deleted, or reinstalled.  That's what I've seen.
>> 
>> According to the docs, (and the scratch files in your /library folder if you 
>> use the simulator, everything is in the app and nowhere else.  If reality is 
>> different, I wonder why it conflicts with what the documentation says.
>> 
>> If "every app is an island", then I don't see how what you say an be true.  
>> I hope you are right, however.
>> 
>> And restricting general access to the file system is a royal PITA.
> 
> Are you talking about iOS or Mac?
> 

For the preferences issue, I am referring to iOS.


> On iOS the sandbox *is* the app. On Mac it is not, so the results will be 
> very different on the two platforms. In general, I'm talking about Mac. I've 
> toyed with iOS development but haven't done anything in anger.
> 
> On Mac, an app's sandbox lives at ~/Library/Containers//...
> 
> 
> 
> --Graham
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Laurent Daudelin]

I think Graham is mostly talking about OS X while you are obviously on iOS, 
Alex….

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

On Aug 22, 2012, at 17:02, Alex Zavatone  wrote:

> Since the preferences folder lives in the app, the preferences are deleted 
> when the app is deleted, or reinstalled. That's what I've seen.
> 
> According to the docs, (and the scratch files in your /library folder if you 
> use the simulator, everything is in the app and nowhere else.  If reality is 
> different, I wonder why it conflicts with what the documentation says.
> 
> If "every app is an island", then I don't see how what you say an be true.  I 
> hope you are right, however.
> 
> And restricting general access to the file system is a royal PITA.
> 
> On Aug 22, 2012, at 7:37 PM, Graham Cox wrote:
> 
>> 
>> On 23/08/2012, at 1:18 AM, Alex Zavatone  wrote:
>> 
>>> Regarding Sandboxing on Mac OS or iOS, the situations I want to see 
>>> addressed are these:
>>> 
>>> The app gets regularly updated.  Preferences must exist out side of the 
>>> app.  What easy and straightforward method that does not require the 
>>> developer to jump through hoops supports preservation of app preferences 
>>> when an app may be deleted or upgraded WITHOUT using "the cloud", as this 
>>> is completely in violation of many companies' policies.
>> 
>> 
>> Well, much as I hate the sandbox implementation (and note, that's the 
>> implementation, not necessarily the concept, though I believe that the 
>> concept as it stands isn't well thought-through) this particular aspect 
>> isn't a major factor.
>> 
>> Your preferences live in your sandbox, to which you have free access without 
>> jumping through any hoops, as long as you use the usual directory discovery 
>> APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app 
>> could be a problem but AFAIK the sandbox for an app is not automatically 
>> deleted if you trash an app in Mac OS (in iOS, that's another thing, as you 
>> have only one means to trash an app and it deletes its sandbox). The sandbox 
>> itself is not inside your app bundle, it lives elsewhere, so you can trash 
>> the app and leave its sandbox behind. Since the sandbox is identified using 
>> the bundle ID, a new version of the app will inherit the old version's 
>> sandbox.
>> 
>> Where life is made difficult is with more general access to the file system, 
>> which is a perfectly legitimate thing to do. A user stores various media all 
>> over the file system and there is no reason why an app shouldn't have access 
>> to it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also 
>> manage media and it is perfectly reasonable for another app to want access 
>> to that data. Doing this in a manner that is consistent across OS versions, 
>> sandboxing, localizations and so on is extremely difficult if not impossible 
>> right now. Apple are severely handcuffing us on the sandboxing front, but 
>> are not giving anything back to sweeten the deal. If they provided a 
>> sanctioned API for accessing media consistently that would go a long way, 
>> for me at least, to accept sandboxing. Trying to work around this is proving 
>> impossible with the current sandbox implementation - there are too many 
>> opaque hacks in the system that mean you cannot trust the URLs you get from 
>> anywhere to actually point to the right place, and you also have to 
>> hard-code paths in your entitlements which are extremely fragile under both 
>> localisation and system updates. (For example, if I add a temporary 
>> entitlement to ~/Pictures/iPhoto Library, if that location changes, or is 
>> named differently, my app stops working. Note the name of the iPhoto Library 
>> did subtly change between 10.7 and 10.8 - the space is a different unicode 
>> character now).
>> 
>> The only bright spot in all of this is the fact that on Mac at least you 
>> have a channel other than the App Store to deliver apps, but since the App 
>> Store is responsible for 90% of our sales, it would be commercial suicide to 
>> leave it. So we're stuck.
>> 
>> The other aspect of this is that the way the App Store staff treat the 
>> developer in the face of sandboxing issues is seriously hurting developer 
>> relations and Apple's image. But that's a separate issue I suppose. I do 
>> remember a time when Apple's developer relations were second-to-none. Oddly, 
>> the company was on death's door at the time. Success (which we've all had a 
>> small part to play in) breeds contempt, it seems.
>> 
>> --Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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

Re: Sandboxing die.die.die

[Graham Cox]

On 23/08/2012, at 10:02 AM, Alex Zavatone  wrote:

> Since the preferences folder lives in the app, the preferences are deleted 
> when the app is deleted, or reinstalled.  That's what I've seen.
> 
> According to the docs, (and the scratch files in your /library folder if you 
> use the simulator, everything is in the app and nowhere else.  If reality is 
> different, I wonder why it conflicts with what the documentation says.
> 
> If "every app is an island", then I don't see how what you say an be true.  I 
> hope you are right, however.
> 
> And restricting general access to the file system is a royal PITA.

Are you talking about iOS or Mac?

On iOS the sandbox *is* the app. On Mac it is not, so the results will be very 
different on the two platforms. In general, I'm talking about Mac. I've toyed 
with iOS development but haven't done anything in anger.

On Mac, an app's sandbox lives at ~/Library/Containers//...



--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[danchik]

A somewhat related question.  It seems that the gatekeeper is mostly 
concenrned with the signature on the installer package and not the software 
it installed.  If the package is signed by Apple Developer's Installer 
certificate, gate keeper does not complain (just askes to ok the 
installation) and then never sais anything about the app that was installed 
(though it is NOT signed by Apples Developer's Software certificate).


So is it important to sign the code as well and not just the package (from 
the usability and end user experience point of view)?



- Original Message - 
From: "Mike Abdullah" 

To: "James Merkel" 
Cc: 
Sent: Wednesday, August 22, 2012 4:44 PM
Subject: Re: Sandboxing die.die.die




On 22 Aug 2012, at 21:31, James Merkel wrote:



On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:


On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:

Notification Center is usable by any app; I'm using it and App Store
isn't even a possibility at this point.


I believe your app has to be code-signed. But any valid code signature
should work.

--Kyle Sluder


However, I don't think you can self sign it can you?


Yes you can. Apple recommend DeveloperID instead though these days. It’s 
$99, pretty easy. Just do it.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/danchik%40rebelbase.com

This email sent to danc...@rebelbase.com 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Zavatone]

Since the preferences folder lives in the app, the preferences are deleted when 
the app is deleted, or reinstalled.  That's what I've seen.

According to the docs, (and the scratch files in your /library folder if you 
use the simulator, everything is in the app and nowhere else.  If reality is 
different, I wonder why it conflicts with what the documentation says.

If "every app is an island", then I don't see how what you say an be true.  I 
hope you are right, however.

And restricting general access to the file system is a royal PITA.

On Aug 22, 2012, at 7:37 PM, Graham Cox wrote:

> 
> On 23/08/2012, at 1:18 AM, Alex Zavatone  wrote:
> 
>> Regarding Sandboxing on Mac OS or iOS, the situations I want to see 
>> addressed are these:
>> 
>> The app gets regularly updated.  Preferences must exist out side of the app. 
>>  What easy and straightforward method that does not require the developer to 
>> jump through hoops supports preservation of app preferences when an app may 
>> be deleted or upgraded WITHOUT using "the cloud", as this is completely in 
>> violation of many companies' policies.
> 
> 
> Well, much as I hate the sandbox implementation (and note, that's the 
> implementation, not necessarily the concept, though I believe that the 
> concept as it stands isn't well thought-through) this particular aspect isn't 
> a major factor.
> 
> Your preferences live in your sandbox, to which you have free access without 
> jumping through any hoops, as long as you use the usual directory discovery 
> APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app could 
> be a problem but AFAIK the sandbox for an app is not automatically deleted if 
> you trash an app in Mac OS (in iOS, that's another thing, as you have only 
> one means to trash an app and it deletes its sandbox). The sandbox itself is 
> not inside your app bundle, it lives elsewhere, so you can trash the app and 
> leave its sandbox behind. Since the sandbox is identified using the bundle 
> ID, a new version of the app will inherit the old version's sandbox.
> 
> Where life is made difficult is with more general access to the file system, 
> which is a perfectly legitimate thing to do. A user stores various media all 
> over the file system and there is no reason why an app shouldn't have access 
> to it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also 
> manage media and it is perfectly reasonable for another app to want access to 
> that data. Doing this in a manner that is consistent across OS versions, 
> sandboxing, localizations and so on is extremely difficult if not impossible 
> right now. Apple are severely handcuffing us on the sandboxing front, but are 
> not giving anything back to sweeten the deal. If they provided a sanctioned 
> API for accessing media consistently that would go a long way, for me at 
> least, to accept sandboxing. Trying to work around this is proving impossible 
> with the current sandbox implementation - there are too many opaque hacks in 
> the system that mean you cannot trust the URLs you get from anywhere to 
> actually point to the right place, and you also have to hard-code paths in 
> your entitlements which are extremely fragile under both localisation and 
> system updates. (For example, if I add a temporary entitlement to 
> ~/Pictures/iPhoto Library, if that location changes, or is named differently, 
> my app stops working. Note the name of the iPhoto Library did subtly change 
> between 10.7 and 10.8 - the space is a different unicode character now).
> 
> The only bright spot in all of this is the fact that on Mac at least you have 
> a channel other than the App Store to deliver apps, but since the App Store 
> is responsible for 90% of our sales, it would be commercial suicide to leave 
> it. So we're stuck.
> 
> The other aspect of this is that the way the App Store staff treat the 
> developer in the face of sandboxing issues is seriously hurting developer 
> relations and Apple's image. But that's a separate issue I suppose. I do 
> remember a time when Apple's developer relations were second-to-none. Oddly, 
> the company was on death's door at the time. Success (which we've all had a 
> small part to play in) breeds contempt, it seems.
> 
> --Graham
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Mike Abdullah]

On 22 Aug 2012, at 21:31, James Merkel wrote:

> 
> On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:
> 
>> On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
>>> Notification Center is usable by any app; I'm using it and App Store
>>> isn't even a possibility at this point.
>> 
>> I believe your app has to be code-signed. But any valid code signature
>> should work.
>> 
>> --Kyle Sluder
> 
> However, I don't think you can self sign it can you?

Yes you can. Apple recommend DeveloperID instead though these days. It’s $99, 
pretty easy. Just do it.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 23/08/2012, at 1:18 AM, Alex Zavatone  wrote:

> Regarding Sandboxing on Mac OS or iOS, the situations I want to see addressed 
> are these:
> 
> The app gets regularly updated.  Preferences must exist out side of the app.  
> What easy and straightforward method that does not require the developer to 
> jump through hoops supports preservation of app preferences when an app may 
> be deleted or upgraded WITHOUT using "the cloud", as this is completely in 
> violation of many companies' policies.


Well, much as I hate the sandbox implementation (and note, that's the 
implementation, not necessarily the concept, though I believe that the concept 
as it stands isn't well thought-through) this particular aspect isn't a major 
factor.

Your preferences live in your sandbox, to which you have free access without 
jumping through any hoops, as long as you use the usual directory discovery 
APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app could 
be a problem but AFAIK the sandbox for an app is not automatically deleted if 
you trash an app in Mac OS (in iOS, that's another thing, as you have only one 
means to trash an app and it deletes its sandbox). The sandbox itself is not 
inside your app bundle, it lives elsewhere, so you can trash the app and leave 
its sandbox behind. Since the sandbox is identified using the bundle ID, a new 
version of the app will inherit the old version's sandbox.

Where life is made difficult is with more general access to the file system, 
which is a perfectly legitimate thing to do. A user stores various media all 
over the file system and there is no reason why an app shouldn't have access to 
it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also 
manage media and it is perfectly reasonable for another app to want access to 
that data. Doing this in a manner that is consistent across OS versions, 
sandboxing, localizations and so on is extremely difficult if not impossible 
right now. Apple are severely handcuffing us on the sandboxing front, but are 
not giving anything back to sweeten the deal. If they provided a sanctioned API 
for accessing media consistently that would go a long way, for me at least, to 
accept sandboxing. Trying to work around this is proving impossible with the 
current sandbox implementation - there are too many opaque hacks in the system 
that mean you cannot trust the URLs you get from anywhere to actually point to 
the right place, and you also have to hard-code paths in your entitlements 
which are extremely fragile under both localisation and system updates. (For 
example, if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that 
location changes, or is named differently, my app stops working. Note the name 
of the iPhoto Library did subtly change between 10.7 and 10.8 - the space is a 
different unicode character now).

The only bright spot in all of this is the fact that on Mac at least you have a 
channel other than the App Store to deliver apps, but since the App Store is 
responsible for 90% of our sales, it would be commercial suicide to leave it. 
So we're stuck.

The other aspect of this is that the way the App Store staff treat the 
developer in the face of sandboxing issues is seriously hurting developer 
relations and Apple's image. But that's a separate issue I suppose. I do 
remember a time when Apple's developer relations were second-to-none. Oddly, 
the company was on death's door at the time. Success (which we've all had a 
small part to play in) breeds contempt, it seems.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Stephane Sudre]

On Wed, Aug 22, 2012 at 5:18 PM, Alex Zavatone  wrote:
> Regarding Sandboxing on Mac OS or iOS, the situations I want to see addressed 
> are these:
>
> The app gets regularly updated.  Preferences must exist out side of the app.  
> What easy and straightforward method that does not require the developer to 
> jump through hoops supports preservation of app preferences when an app may 
> be deleted or upgraded WITHOUT using "the cloud", as this is completely in 
> violation of many companies' policies.
>
> If you never ever submit apps to the app store, or you have your own managed 
> app store and develop apps solely for the enterprise, and never mass market 
> apps, then be it on iOS or Mac OS, you are expected to have access outside of 
> the sandbox.  It is expected that you will have access to the device and 
> different folders to create useful software.

I don't see why you have to care about the Sandbox in the case you
describe. The only issue there could be so far at that time is you
would have to codesign/productsign your application/installation
packages for 10.8 and pay the Gatekeeper rent.

Moreover, Gatekeeper is so easy to work around when you have control
on the way your application is deployed (which you seem to have in the
case you describe) that you could even get away without
codesigning/productsigning your products for OS X 10.8.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[James Merkel]

On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:

> On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
>> Notification Center is usable by any app; I'm using it and App Store
>> isn't even a possibility at this point.
> 
> I believe your app has to be code-signed. But any valid code signature
> should work.
> 
> --Kyle Sluder

However, I don't think you can self sign it can you?

Jim Merkel
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Kyle Sluder]

On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
> Notification Center is usable by any app; I'm using it and App Store
> isn't even a possibility at this point.

I believe your app has to be code-signed. But any valid code signature
should work.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Lee Ann Rucker]

On Aug 22, 2012, at 12:51 PM, Alex Kac wrote:

> There are some MAS-only features such as Notification Center (I believe) and 
> iCloud, so its quite nice to be able to use those features.

Notification Center is usable by any app; I'm using it and App Store isn't even 
a possibility at this point.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[James Merkel]

Ok, for my particular application I don't see any need for iCloud or 
Notification center. For other applications, YMMV.

Jim Merkel

On Aug 22, 2012, at 12:51 PM, Alex Kac  wrote:

> There are some MAS-only features such as Notification Center (I believe) and 
> iCloud, so its quite nice to be able to use those features.
> 
> On Aug 22, 2012, at 2:42 PM, James Merkel  wrote:
> 
>> Why not just codeSign an application? It will still will be able to be 
>> downloaded by anyone using the default security  setting: "Mac App Store and 
>> identified developers". It just won't be able to be in the App store (I 
>> guess).
>> 
>> Jim Merkel
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net
>> 
>> This email sent to a...@webis.net
> 
> Alex Kac - President and Founder
> Web Information Solutions, Inc.
> 
> “Don't forget until too late that the business of life is not business but 
> living.”
> -- B.C. Forbes,
> 
> 
> 
> 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Kac]

There are some MAS-only features such as Notification Center (I believe) and 
iCloud, so its quite nice to be able to use those features.

On Aug 22, 2012, at 2:42 PM, James Merkel  wrote:

> Why not just codeSign an application? It will still will be able to be 
> downloaded by anyone using the default security  setting: "Mac App Store and 
> identified developers". It just won't be able to be in the App store (I 
> guess).
> 
> Jim Merkel
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net
> 
> This email sent to a...@webis.net

Alex Kac - President and Founder
Web Information Solutions, Inc.

“Don't forget until too late that the business of life is not business but 
living.”
-- B.C. Forbes,





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[James Merkel]

Why not just codeSign an application? It will still will be able to be 
downloaded by anyone using the default security  setting: "Mac App Store and 
identified developers". It just won't be able to be in the App store (I guess).

Jim Merkel
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Jayson Adams]

On Aug 22, 2012, at 8:40 AM, Kyle Sluder wrote:

> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
> 
>> 
>> Ah, that explains why all of Apple's apps are sandboxed  Right.
> 
> The big ones are: Mail, Safari, Preview.

How about Finder? AddressBook?  Calendar? iPhoto?  Pages?  Numbers?  And. On. 
And. On.

> But arguing against the basic premise of sandboxing is a fruitless endeavor. 
> The user cannot and should not be forced to trust you to do the right thing.


I aren't arguing against that (not that I am in agreement either).  I am 
arguing against this statement:

> Because in the face of a successful attack, "you" might not be the author of 
> the executing code either.

That's Apple positioning for the reason behind sandboxing of developer apps but 
I mean really, if I'm a hacker I'm going to go after the biggest target out 
there (you know, Finder, AddressBook, Calendar, etc.).  I'm wouldn't waste my 
time with third-party apps when there are lots of other targets that come 
pre-installed on every single machine.

Best,


__jayson

Circus Ponies NoteBook - Introducing An App That Boosts Your Productivity
at Work or School, So You Get The Grades, Raises and Promotions You Want.

www.circusponies.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Kyle Sluder]

On Aug 22, 2012, at 9:26 AM, Alex Zavatone  wrote:

> 
> On Aug 22, 2012, at 12:01 PM, Derek Chesterfield wrote:
> 
>> They can *expect* that you will do the right thing. But they can't be 
>> expected to *know* that you really are. 
> 
> Well, if I don't, I get fired.  That's enough motivation for me.

If fear of failure were enough to write bug-free code we could've replaced gdb 
with a firing squad a long time ago.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Zavatone]

On Aug 22, 2012, at 12:01 PM, Derek Chesterfield wrote:

> They can *expect* that you will do the right thing. But they can't be 
> expected to *know* that you really are. 

Well, if I don't, I get fired.  That's enough motivation for me.


> On 22 Aug 2012, at 16:52, Alex Zavatone  wrote:
> 
>> 
>> On Aug 22, 2012, at 11:40 AM, Kyle Sluder wrote:
>> 
>>> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
>>> 
 
 Ah, that explains why all of Apple's apps are sandboxed  Right.
>>> 
>>> The big ones are: Mail, Safari, Preview.
>>> 
>>> There have been legitimate problems with the rollout of sandboxing. It 
>>> doesn't support certain interactions that are fundamental to some apps, and 
>>> yet it was forced upon them by the MAS. Sandboxing errors are opaque, and 
>>> code signing is cryptic.
>>> 
>>> But arguing against the basic premise of sandboxing is a fruitless 
>>> endeavor. The user cannot and should not be forced to trust you to do the 
>>> right thing.
>>> 
>>> --Kyle Sluder
>> 
>> Actually Kyle, when you're not catering to the mass market, but targeted 
>> clients, the user requires you to do the right thing.  
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/dez%40mac.com
>> 
>> This email sent to d...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Zavatone]

On Aug 22, 2012, at 12:00 PM, Kyle Sluder wrote:

> On Aug 22, 2012, at 8:52 AM, Alex Zavatone  wrote:
> 
>> 
>> Actually Kyle, when you're not catering to the mass market, but targeted 
>> clients, the user requires you to do the right thing.  
> 
> And the OS enforceS that requirement on their behalf by sandboxing.

Actually, it creates much more problems for us than it solves and forces us to 
bypass the sandbox, resulting in additional costs to our company that easily 
reach into the tens of thousands of dollars.

> Thankfully we have Developer ID to provide an escape hatch and alternate 
> distribution mechanism while the sandboxing implementation is fixed, but the 
> basic concept of sandboxing is not going anywhere.
> 

How does this help?

> --Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Scott Ribe]

On Aug 22, 2012, at 9:52 AM, Alex Zavatone wrote:

> Actually Kyle, when you're not catering to the mass market, but targeted 
> clients, the user requires you to do the right thing.  

For some of us, that even includes contracts which put actual liability on us 
for failures, and require us to carry 7 figures' worth of insurance to cover 
that liability. So yes, in some cases, the user (and insurer) absolutely 
expects us to do the right thing.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Derek Chesterfield]

They can *expect* that you will do the right thing. But they can't be expected 
to *know* that you really are. 

On 22 Aug 2012, at 16:52, Alex Zavatone  wrote:

> 
> On Aug 22, 2012, at 11:40 AM, Kyle Sluder wrote:
> 
>> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
>> 
>>> 
>>> Ah, that explains why all of Apple's apps are sandboxed  Right.
>> 
>> The big ones are: Mail, Safari, Preview.
>> 
>> There have been legitimate problems with the rollout of sandboxing. It 
>> doesn't support certain interactions that are fundamental to some apps, and 
>> yet it was forced upon them by the MAS. Sandboxing errors are opaque, and 
>> code signing is cryptic.
>> 
>> But arguing against the basic premise of sandboxing is a fruitless endeavor. 
>> The user cannot and should not be forced to trust you to do the right thing.
>> 
>> --Kyle Sluder
> 
> Actually Kyle, when you're not catering to the mass market, but targeted 
> clients, the user requires you to do the right thing.  
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/dez%40mac.com
> 
> This email sent to d...@mac.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Kyle Sluder]

On Aug 22, 2012, at 8:52 AM, Alex Zavatone  wrote:

> 
> Actually Kyle, when you're not catering to the mass market, but targeted 
> clients, the user requires you to do the right thing.  

And the OS enforceS that requirement on their behalf by sandboxing.

Thankfully we have Developer ID to provide an escape hatch and alternate 
distribution mechanism while the sandboxing implementation is fixed, but the 
basic concept of sandboxing is not going anywhere.

--Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Zavatone]

On Aug 22, 2012, at 11:40 AM, Kyle Sluder wrote:

> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
> 
>> 
>> Ah, that explains why all of Apple's apps are sandboxed  Right.
> 
> The big ones are: Mail, Safari, Preview.
> 
> There have been legitimate problems with the rollout of sandboxing. It 
> doesn't support certain interactions that are fundamental to some apps, and 
> yet it was forced upon them by the MAS. Sandboxing errors are opaque, and 
> code signing is cryptic.
> 
> But arguing against the basic premise of sandboxing is a fruitless endeavor. 
> The user cannot and should not be forced to trust you to do the right thing.
> 
> --Kyle Sluder

Actually Kyle, when you're not catering to the mass market, but targeted 
clients, the user requires you to do the right thing.  

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Kyle Sluder]

On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:

> 
> Ah, that explains why all of Apple's apps are sandboxed  Right.

The big ones are: Mail, Safari, Preview.

There have been legitimate problems with the rollout of sandboxing. It doesn't 
support certain interactions that are fundamental to some apps, and yet it was 
forced upon them by the MAS. Sandboxing errors are opaque, and code signing is 
cryptic.

But arguing against the basic premise of sandboxing is a fruitless endeavor. 
The user cannot and should not be forced to trust you to do the right thing.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Jayson Adams]

On Aug 21, 2012, at 11:54 PM, Kyle Sluder  wrote:

> On Aug 21, 2012, at 11:02 PM, Jens Alfke  wrote:
> 
>> 
>> But then, I haven't tried sandboxing yet. It sounds almost like some 
>> exquisite form of BDSM: taking away all of your freedom and then making you 
>> beg to get little bits back. Does it come with safe-words?
> 
> Irrespective of everything else, this is indeed the model for sandboxing. 
> Because "you" is not normally synonymous with "the user", and the industry 
> has awoken to the reality that the user can not trust your motives to be 
> pure. Because in the face of a successful attack, "you" might not be the 
> author of the executing code either.

Ah, that explains why all of Apple's apps are sandboxed  Right.

__jayson
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Alex Zavatone]

Regarding Sandboxing on Mac OS or iOS, the situations I want to see addressed 
are these:

The app gets regularly updated.  Preferences must exist out side of the app.  
What easy and straightforward method that does not require the developer to 
jump through hoops supports preservation of app preferences when an app may be 
deleted or upgraded WITHOUT using "the cloud", as this is completely in 
violation of many companies' policies.

If you never ever submit apps to the app store, or you have your own managed 
app store and develop apps solely for the enterprise, and never mass market 
apps, then be it on iOS or Mac OS, you are expected to have access outside of 
the sandbox.  It is expected that you will have access to the device and 
different folders to create useful software.

Honestly, Sandboxing seems to be created by people who have written a few 
papers on security.  But the implications of Sandboxing mean that there will be 
less documentation for people to refer to and the restrictions placed on the 
developers mean that files in supported folders will be co-opted to serve as 
cookies or data structures that will outlast an app's deletion, thereby already 
bypassing the restrictions Apple is trying to impose.

Apple has created a royal PITA for developers who don't care about submitting 
apps to the general public, both on iOS and on Mac OS and created a much less 
useful environment in the process.  
 
If Apple limited the restricted folders to the System and Library folders off 
the root, this would be a whole lot less of a PITA.  Just let us write to the 
drive outside of the folders that contain the precious internal important bits. 
 Stop handcuffing your developers.



On Aug 22, 2012, at 2:54 AM, Kyle Sluder wrote:

> On Aug 21, 2012, at 11:02 PM, Jens Alfke  wrote:
> 
>> 
>> But then, I haven't tried sandboxing yet. It sounds almost like some 
>> exquisite form of BDSM: taking away all of your freedom and then making you 
>> beg to get little bits back. Does it come with safe-words?
> 
> Irrespective of everything else, this is indeed the model for sandboxing. 
> Because "you" is not normally synonymous with "the user", and the industry 
> has awoken to the reality that the user can not trust your motives to be 
> pure. Because in the face of a successful attack, "you" might not be the 
> author of the executing code either.
> 
> --Kyle Sluder
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Kyle Sluder]

On Aug 21, 2012, at 11:02 PM, Jens Alfke  wrote:

> 
> But then, I haven't tried sandboxing yet. It sounds almost like some 
> exquisite form of BDSM: taking away all of your freedom and then making you 
> beg to get little bits back. Does it come with safe-words?

Irrespective of everything else, this is indeed the model for sandboxing. 
Because "you" is not normally synonymous with "the user", and the industry has 
awoken to the reality that the user can not trust your motives to be pure. 
Because in the face of a successful attack, "you" might not be the author of 
the executing code either.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Laurent Daudelin]

On Aug 21, 2012, at 22:45, Graham Cox  wrote:

> 
> On 22/08/2012, at 2:46 PM, Laurent Daudelin  wrote:
> 
>> That's really bad news. I have a synchronization app on the App Store and I 
>> was hoping to update it with those security-scoped URLs but if it doesn't 
>> work for the content of folders, then I'm hosed.
> 
> OK, I think I see what needs to happen.
> 
> The documentation isn't crystal clear, because it seems to suggest that you 
> would use -startAccessing and -stopAccessing whenever you need to access a 
> resource using the URL, which is what I attempted to do. However, there are 
> so many places in the system that open files using a URL that clearly do not 
> do this (and hence fall foul of the wicked witch of the north, er, I mean 
> sandboxd) that I started to wonder whether my interpretation was correct.
> 
> So I read the documentation literally. It says as soon as you resolve a 
> bookmark, do the startAccessing thing. Then when you're finished (in my case 
> my URL is owned by an object of mine, so I can do it in -dealloc) do the 
> -stopAccessing thing. In other words leave it "open" all the time.
> 
> Sure enough, that does now appear to work, allowing access to the folder and 
> all of the files and folders within it.
> 
> I'm still falling foul of sandboxd in a few other areas that seem a bit 
> strange, like dragging and dropping files. It appears to ask the system for a 
> sandboxing extension for the drag but fails internally, even though I do have 
> permission thanks to the above. So this would appear to be an unrelated issue.
> 
>> the whole sandboxing enchilada seemed to be something that was quickly put 
>> together without much thought.
> 
> 
> Understatement of the century :)
> 
> I bet if there were a cost/benefit analysis done on sandboxing, taking into 
> account all of the time, effort and stress it is causing external developers, 
> it would clearly be an outstandingly pointless exercise.
> 
> 
> --Graham

Thanks, Graham, I can now starting to breath normally! I might have a few 
questions when I'm ready to take my app to the next step, but that's not 
happening anytime soon.

Thanks for the follow-up!

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Jens Alfke]

On Aug 21, 2012, at 8:47 PM, Graham Cox  wrote:

> Is sandboxing the MOST HATEFUL and useless API Apple have ever created? I 
> can't think of a worse one in 30 years

It would be hard to beat the iOS Keychain API (which they are now trying to 
foist upon us in OS X by deprecating the old serviceable one.)

It looks cleaner than the old API because it has fewer functions to call, but 
once you skim through the hundreds of attribute constants you quickly realize 
it's like unto a huge bag of unlabeled Lego pieces, which will fall all over 
the floor and stab you in the feet when you try to walk anywhere. The 
instructions are just a crudely Xeroxed sheet showing two bricks and saying 
"PLEASE INSERTING OF TAB A IN SLOT B. REPEAT."

But then, I haven't tried sandboxing yet. It sounds almost like some exquisite 
form of BDSM: taking away all of your freedom and then making you beg to get 
little bits back. Does it come with safe-words?

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 22/08/2012, at 2:46 PM, Laurent Daudelin  wrote:

> That's really bad news. I have a synchronization app on the App Store and I 
> was hoping to update it with those security-scoped URLs but if it doesn't 
> work for the content of folders, then I'm hosed.

OK, I think I see what needs to happen.

The documentation isn't crystal clear, because it seems to suggest that you 
would use -startAccessing and -stopAccessing whenever you need to access a 
resource using the URL, which is what I attempted to do. However, there are so 
many places in the system that open files using a URL that clearly do not do 
this (and hence fall foul of the wicked witch of the north, er, I mean 
sandboxd) that I started to wonder whether my interpretation was correct.

So I read the documentation literally. It says as soon as you resolve a 
bookmark, do the startAccessing thing. Then when you're finished (in my case my 
URL is owned by an object of mine, so I can do it in -dealloc) do the 
-stopAccessing thing. In other words leave it "open" all the time.

Sure enough, that does now appear to work, allowing access to the folder and 
all of the files and folders within it.

I'm still falling foul of sandboxd in a few other areas that seem a bit 
strange, like dragging and dropping files. It appears to ask the system for a 
sandboxing extension for the drag but fails internally, even though I do have 
permission thanks to the above. So this would appear to be an unrelated issue.

> the whole sandboxing enchilada seemed to be something that was quickly put 
> together without much thought.


Understatement of the century :)

I bet if there were a cost/benefit analysis done on sandboxing, taking into 
account all of the time, effort and stress it is causing external developers, 
it would clearly be an outstandingly pointless exercise.


--Graham
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing die.die.die

[Graham Cox]

On 22/08/2012, at 1:47 PM, Graham Cox  wrote:

> The problem is that all of the files and folders INSIDE the folder created 
> from the security bookmark are being disallowed by sandboxd



Here's a typical refusal report.

22/08/12 2:44:33.229 PM sandboxd[64627]: ([64596]) Artboard(64596) deny 
file-read-data /Users/grahamcox/Documents/Artboard Test Files/Clip Art - 
InAppPurchases/Design Elements Pack 1/GazetteScroll.svg
Artboard(64596) deny file-read-data /Users/grahamcox/Documents/Artboard Test 
Files/Clip Art - InAppPurchases/Design Elements Pack 1/GazetteScroll.svg

[]

Thread 0:
0   libsystem_kernel.dylib  0x000103e60fee __open + 10
1   CoreFoundation  0x0001011ba0c9 _CFStreamOpen + 137
2   CoreFoundation  0x0001011dbb76 CFReadStreamOpen + 86
3   Foundation  0x000100c86abd -[NSXMLParser 
parseFromStream] + 44
4   Foundation  0x000100c86bed -[NSXMLParser parse] 
+ 67
5   GCDrawKit   0x000100877972 -[DKSVGImporter 
drawing] + 195 (DKSVGImporter.m:352)
6   GCDrawKit   0x0001008cd7f5 -[DKSVGPreview 
_dk_threadEntry] + 137 (DKSVGPreview.m:519)
7   CoreFoundation  0x00010120ecac __invoking___ + 140
8   CoreFoundation  0x00010120eb47 -[NSInvocation 
invoke] + 263
9   Foundation  0x000100b5ed10 
-[NSInvocationOperation main] + 34
10  Foundation  0x000100b56bb6 
-[__NSOperationInternal start] + 684
11  Foundation  0x000100b5e3d1 __block_global_6 + 
129
12  libdispatch.dylib   0x000103c7cf3d 
_dispatch_call_block_and_release + 15
13  libdispatch.dylib   0x000103c790fa 
_dispatch_client_callout + 8
14  libdispatch.dylib   0x000103c7a23e 
_dispatch_worker_thread2 + 304
15  libsystem_c.dylib   0x000103cfaceb _pthread_wqthread + 
404
16  libsystem_c.dylib   0x000103ce51b1 start_wqthread + 13

As you can see, I'm parsing XML (in fact SVG) on a thread which is queued using 
an NSInvocationOperation. The object that handles this chore is passed a NSURL 
which tells it which file to parse. I have been very careful to derive that URL 
from the grandparent URL which was created by decoding a saved security-scoped 
bookmark, but nevertheless this URL does not appear to inherit the security 
scoping of its (grand)parent. So, despite the fact that I'm bracketing the 
calls to [NSXMLParser parse] with the necessary incantations for security 
scoping, sandboxd is still being the obstreperous refusnik that we all know and 
loathe.

Is there something else I need to be doing to ensure derived URLs inherit the 
security scoping of the parent URL? 

I suspect that if I start and stop security scoping at this point on the 
grandparent folder, it will probably work (something I need to try), but that 
information is LONG gone by the time this method is asked to run by the 
invocation (and why not? After all the URL is supposed to encapsulate all the 
information it needs at this point, and with the exception of the sandboxing 
mysticism, it does). There's also a question as to whether those methods are 
thread-safe.

The code that derives these URLs is (simplified):

[self startSecurityAccess];

NSError* error;
NSArray* keys = [NSArray arrayWithObjects:NSURLIsDirectoryKey, 
NSURLIsHiddenKey, NSURLPathKey, nil];

NSDirectoryEnumerator* all = [[NSFileManager defaultManager] 
enumeratorAtURL:[self URL] << this URL is derived from saved 
security-scoped bookmark data

  includingPropertiesForKeys:keys

 
options:NSDirectoryEnumerationSkipsSubdirectoryDescendants | 
NSDirectoryEnumerationSkipsHiddenFiles

errorHandler:nil];

for( NSURL* sp in all )
{
NSNumber* isDirectory;

if([sp getResourceValue:&isDirectory 
forKey:NSURLIsDirectoryKey error:&error])
{
if(![isDirectory boolValue])
{
// it's a file, use this URL<<- 
this URL does not inherit the necessary security scoping of the folder being 
enumerated
}
}
}

[self stopSecurityAccess];

Here, my methods -

Re: Sandboxing die.die.die

[Laurent Daudelin]

On Aug 21, 2012, at 20:47, Graham Cox  wrote:

> Is sandboxing the MOST HATEFUL and useless API Apple have ever created? I 
> can't think of a worse one in 30 years
> 
> 
> Anyway ranting aside,
> 
> I have a browser which allows the user to add folders to a source list and it 
> then scans that folder for image files and displays them, including in any 
> subfolders. The user can select subfolders to narrow down the list of images.
> 
> When the app is quit, the list of folders is saved so that it can be restored 
> next time. Previous to sandboxing, that was easy.
> 
> Now, it's a seriously difficult proposition. Here's what I'm doing:
> 
> The user adds folders to the browser using the standard NSOpenPanel, so the 
> URL is automatically allowed by the sandbox, and can be bookmarked using a 
> security scoped bookmark. I've added the entitlement to allow app-wide 
> security-scoped bookmarks to work.
> 
> Next session, the saved bookmarks are resolved and the browser UI restored. 
> That now works (after much hair-pulling).
> 
> 
> Now, whenever a security-scoped URL must be accessed, you have to bracket 
> that with -startAccessingSecurityScopedResource and 
> -stopAccessingSecurityScopedResource, which in itself is painful because this 
> method isn't available prior to 10.7.3, so you have to additionally check 
> whether the URL responds to that selector, but no matter, I'm jumping through 
> that flaming hoop OK. (I assume that my users on 10.7 earlier than 10.7.3 
> will just have to put up with the fact that none of this will work at all. 
> Thanks Apple).
> 
> The problem is that all of the files and folders INSIDE the folder created 
> from the security bookmark are being disallowed by sandboxd despite doing 
> this, presumably because those URLs don't contain the magic sauce that allows 
> it to work - they are created by scanning the parent folder. Apparently URLs 
> within a scoped folder don't inherit the ability to allow access using these 
> methods. Fixing this is going to be extremely hard - a URL is supposed to 
> encapsulate all of the information about the location of a file without 
> reference to another URL elsewhere that happens to be the folder which 
> contains it (and which does have the magic sauce).
> 
> It is clearly impractical to save a security bookmark for every single file - 
> there can be tens of thousands - and for the case of adding the folder using 
> the NSOpenPanel it works OK, so surely there has to be a way to propagate the 
> security access from a folder to all of the folders and files it contains?
> 
> Or is this a use-case that once again has been overlooked in the unseemly 
> rush to push sandboxing on us?
> 

That's really bad news. I have a synchronization app on the App Store and I was 
hoping to update it with those security-scoped URLs but if it doesn't work for 
the content of folders, then I'm hosed.

Have you filed an enhancement request? It might well be a short sightseeing 
from Apple as the whole sandboxing enchilada seemed to be something that was 
quickly put together without much thought.

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Sandboxing die.die.die

[Graham Cox]

Is sandboxing the MOST HATEFUL and useless API Apple have ever created? I can't 
think of a worse one in 30 years


Anyway ranting aside,

I have a browser which allows the user to add folders to a source list and it 
then scans that folder for image files and displays them, including in any 
subfolders. The user can select subfolders to narrow down the list of images.

When the app is quit, the list of folders is saved so that it can be restored 
next time. Previous to sandboxing, that was easy.

Now, it's a seriously difficult proposition. Here's what I'm doing:

The user adds folders to the browser using the standard NSOpenPanel, so the URL 
is automatically allowed by the sandbox, and can be bookmarked using a security 
scoped bookmark. I've added the entitlement to allow app-wide security-scoped 
bookmarks to work.

Next session, the saved bookmarks are resolved and the browser UI restored. 
That now works (after much hair-pulling).


Now, whenever a security-scoped URL must be accessed, you have to bracket that 
with -startAccessingSecurityScopedResource and 
-stopAccessingSecurityScopedResource, which in itself is painful because this 
method isn't available prior to 10.7.3, so you have to additionally check 
whether the URL responds to that selector, but no matter, I'm jumping through 
that flaming hoop OK. (I assume that my users on 10.7 earlier than 10.7.3 will 
just have to put up with the fact that none of this will work at all. Thanks 
Apple).

The problem is that all of the files and folders INSIDE the folder created from 
the security bookmark are being disallowed by sandboxd despite doing this, 
presumably because those URLs don't contain the magic sauce that allows it to 
work - they are created by scanning the parent folder. Apparently URLs within a 
scoped folder don't inherit the ability to allow access using these methods. 
Fixing this is going to be extremely hard - a URL is supposed to encapsulate 
all of the information about the location of a file without reference to 
another URL elsewhere that happens to be the folder which contains it (and 
which does have the magic sauce).

It is clearly impractical to save a security bookmark for every single file - 
there can be tens of thousands - and for the case of adding the folder using 
the NSOpenPanel it works OK, so surely there has to be a way to propagate the 
security access from a folder to all of the folders and files it contains?

Or is this a use-case that once again has been overlooked in the unseemly rush 
to push sandboxing on us?

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com