• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSSecureCoding with containers (or, is NSArray lying?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSecureCoding with containers (or, is NSArray lying?)


  • Subject: Re: NSSecureCoding with containers (or, is NSArray lying?)
  • From: Roland King <email@hidden>
  • Date: Thu, 16 Jul 2015 09:49:24 +0800

> On 16 Jul 2015, at 08:30, André Francisco <email@hidden> wrote:
>
> Hi all,
> I posted a question at SO (http://stackoverflow.com/questions/31307331/how-to-use-nssecurecoding-with-id-objects) and despite the bounty it still didn't get any answers. I am not confident that it will either.
> The problem is when implementing NSSecureCoding with a collection (or container) given that the type of contained objects is not known. I would assume that secure coding is not possible in this situation. However, classes such as NSArray do implement NSSecureCoding, so as I stated earlier, either there's a work around or NSArray is lying.
> I've been putting some effort into this issue in the last few days, so far with no success. But it's been boggling me. So which one is it, can containers/collections implement actual secure coding?
> Best to you all,André.
> _______________________________________________


I’m sure there used to be an SDK guide about this but I can’t find it and Google can’t find it. It included a section on how container types worked with NSSecureCoding. It was in the XPC section I thought.

Anyway they do work. Try it. Make an NSArray of normal stuff, like NSString, NSNumber, encode it, decode it with decodeObjectForClasses, with no classes. You’ll fail on the array. Add the NSArray to the list of allowed classes and .. it works. So, you think, NSArray will blindly decode anything so it’s no-longer secure.

Add an object of a custom class which implements secure coding into the array, and it will start failing again. NSArray, and the other collection types, allow elements of known secure system types, like NSString, but fail at anything outside that. You have to add all the custom classes you will have in any of the collections at any level into your decodeObjectWithClasses() list before the collection classes will work.

Hence, as long as you know all the possible things which could be encoded in your list and they all support secure coding and you list them all in your decode code, you’re fine. That’s really the point, your code says what objects it expects/will accept and that enforces the secure aspect all the way down as you can’t have a class you didn’t expect and every one of the classes you do expect will be securely decoded.
_______________________________________________

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


  • Follow-Ups:
    • RE: NSSecureCoding with containers (or, is NSArray lying?)
      • From: André Francisco <email@hidden>
References: 
 >NSSecureCoding with containers (or, is NSArray lying?) (From: André Francisco <email@hidden>)

  • Prev by Date: Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
  • Next by Date: RE: NSSecureCoding with containers (or, is NSArray lying?)
  • Previous by thread: NSSecureCoding with containers (or, is NSArray lying?)
  • Next by thread: RE: NSSecureCoding with containers (or, is NSArray lying?)
  • Index(es):
    • Date
    • Thread