On 29 Jul 2011, at 23:54, wadesli...@mac.com 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 (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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
