> On Jun 17, 2014, at 8:00 AM, Mike Abdullah <mabdul...@karelia.com> wrote: > > > On 17 Jun 2014, at 15:50, Sean McBride <s...@rogue-research.com> wrote: > >> On Tue, 17 Jun 2014 09:17:46 +0100, Mike Abdullah said: >> >>> I suspect the rationale might be “NSColor and NSImage live in AppKit, >>> not Foundation, and the AppKit engineers aren’t so bothered about secure >>> coding" >> >> That's a good theory. So I just looked through Foundation and found >> numerous other clases that only conform to NSCoding and not NSSecureCoding >> like NSAffineTransform, NSAttributedString, NSCharacterSet, etc. >> >> I guess I should conclude that NSSecureCoding is not a general replacement >> for NSCoding and only really meant for XPC, and that Apple hasn't found much >> use for sending those kinds of objects between processes. > > Ah, it was a nice theory, but no more than a theory then. Oh well! I think > your analysis about it coming down to XPC is probably nearer the mark. > >
The main purpose for secure coding is for NSXPCConnection, but NSKeyedArchiver and NSKeyedUnarchiver also support secure coding as of 10.9. In “regular” coding, the name of the class that is created is stored in the archive and the unarchiver trusts it when it goes to allocate it during decoding. In secure coding, the name of the class is in the archive, but since the decoder also specifies a class as an argument (to -decodeObjectOfClass:forKey:), the decoder can double-check that the class in the archive is something that the caller expects. There is actually series of checks performed here. By adopting the NSSecureCoding protocol, a class is declaring that not only has it switched to specifying classes when it decodes (again, with -decodeObjectOfClass:forKey:) but that the initWithCoder: method has been audited for other kinds of security risks as well. So we didn’t automatically upgrade all NSCoding classes to NSSecureCoding because we wanted to make sure that they were (a) appropriate for sending across a security boundary in the first place and (b) safe to do so. The framework in which a class lives is not really a factor in determining if it should adopt NSSecureCoding or not. If you run into a class which you wish adopted secure coding, then please file a bug. We do already have plenty of requests for NSColor, NSImage, and NSAttributedString. - Tony _______________________________________________ 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
