;>> 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.di
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.
>
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 admi
...@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
t 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.di
> 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: Sandboxi
t; 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
>
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
Co
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
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
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 Sandboxi
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 wit
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 s
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
___
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
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 doin
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];
>> NS
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
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 Kare
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
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 t
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
> +fileURLWith
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 yo
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 do
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 val
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
>
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
>>
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 alt
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
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 i
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 an
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
ins
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
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 t
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
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
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
>>
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
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:
> Sen
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'
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 M
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.
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 scr
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 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 simulato
al 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 A
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
d
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
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 devel
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 de
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 signatur
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
_
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
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 abl
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 de
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-de
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 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
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 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 b
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 ca
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 expla
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 provi
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.
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
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. Doe
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 pref
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,
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
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 serv
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 happe
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
f
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 tha
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
s
74 matches
Mail list logo
