Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- Subject: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- From: Thomas Davie <email@hidden>
- Date: Sat, 30 Jul 2011 09:22:16 +0100
On 29 Jul 2011, at 23:54, email@hidden wrote:
>> When invoking -archivedDataWithRootObject: on, say, dictionary, finding an un-encodeable object buried somewhere in the dictionary would seem to be quite common. Similarly, when invoking -unarchiveObjectWithFile:, no programmer can guarantee what may be found on the filesystem.
>
> And this is one of several concerns with the NSCoding system. It may be that the reason these classes haven't been updated is because there's consternation over the value of such an update. Some people consider NSCoding intractably insecure and ergo unsuitable for use in pretty much anything. Others take issue with it for varied other reasons. I personally like it, but it's not flawless.
>
> I wouldn't stress too much over it, in any case. Sooner or later a change will occur. 'til then, follow the best practices to date.
I'm not sure really what the argument here is. What both of you seem to be asserting is "you could construct any object from a file… that file might be maliciously structured to construct objects that behave in evil ways". This is true, but I'm not sure I see how this differs for *any* API that reads from the file system and constructs objects (as any file loading has to do). Can you give me an example of something that NSCoding (particularly when using keyed archiving) doesn't deal with cleanly, that leads to a security problem not found in other file loading schemes?
Thanks
Tom Davie_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden