Hi André, The way that NSSecureCoding works is by creating a stack of allowed classes. When a class calls decodeObjectOfClasses:forKey:, the classes argument is pushed onto the stack. If it calls decodeObjectForKey:, then nothing is pushed onto the stack. When decoding, the decoder looks at the top item on the stack to see what is allowed.
NSArray (and other collections) use the second mechanism (not pushing on the stack). This means that the set of allowed classes is whatever the decoder of the NSArray instance set up when calling decodeObjectOfClasses:forKey:. This usually means that when decoding an array you want to specify the union of the NSArray class and the expected classes of the array. If you have a class like NSError, which supports secure coding and also has a user info dictionary which can contain arbitrary classes, then you can use the -allowedClasses method on the coder to find the current item on the top of the stack, make a new set with those classes + classes you want to make sure the user info can contain (for e.g. your own contents), then use the decodeObjectOfClasses:forKey: method. As to the purpose of secure coding, the main purpose is to avoid calling +alloc or -initWithCoder: on an arbitrary class. The unarchiver would not call an arbitrary selector when decoding in the first place. Hope this helps, - Tony > On Jul 17, 2015, at 6:03 AM, André Francisco <andre.frate...@hotmail.com> > wrote: > > Hm. I was specifically thinking of unrecognised selector exceptions, although > I might have came up with a much more dangerous scenario: recognised > selectors. What happens if the instantiated class *does* recognise the > selector, but it doesn't quite do what you think it does. Say, -open, or > -unlock. How dangerous is it to call such a selector on an instance of > unknown type? Quite, I think. And it might lead to exploits. I guess that > it's not safe to assume that without type checking the contained instances > you'll be safe from exploits. But definitely the most immediate threat is > just crashing the app. > Cheers. > >> Subject: Re: NSSecureCoding with containers (or, is NSArray lying?) >> From: graham....@bigpond.com >> Date: Fri, 17 Jul 2015 09:52:33 +1000 >> CC: r...@rols.org; cocoa-dev@lists.apple.com >> To: andre.frate...@hotmail.com >> >> >>> On 16 Jul 2015, at 12:17 pm, André Francisco <andre.frate...@hotmail.com> >>> wrote: >>> >>> This can easily crash an app if I get a type that I'm not expecting, even >>> if it implements NSSecureCoding. >> >> >> Actually, probably not. It will likely start throwing exceptions all over >> the place, which *may* cause termination, but it won’t crash in a way that >> could lead to an exploit. >> >> —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/anthony.parker%40apple.com > > This email sent to anthony.par...@apple.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
