Re: NSSecureCoding....

[Richard Frith-Macdonald]

> On 9 Nov 2019, at 11:40, Gregory Casamento <greg.casamento@gmail.com> wrote:
> 
> Does anyone have any clue how we are going to tackle NSSecureCoding?

I don't really understand it.

The basic principle of it is simple: make hacking of archives by an attacker 
harder by preventing the attacker from substituting different classes into the 
archive.

This uses a new -decodeObjectOfClass:forKey: method to decode objects of a 
specific class (easy to implement), plus a trivial method/property 
-supportsSecureCoding  to say whether a class does secure coding or not.

So the alterations are simple, but extensive and time consuming to implement 
(we'd need to retrofit/add this to decoding of most classes).

My problem with it is that it's hard to see how it can work when it comes to 
collections ... yet the Apple documentation says that (for instance) NSSet 
supports secure coding.
That should mean that an NSSet decodes its contents with 
-decodeObjectOfClass:forKey: specifying the class of each object the set holds.
However, a set holds arbitrary values (any class), so presumably it would have 
to decode its contents using NSObject as the class, effectively that's the same 
as using -decodeObjectForKey: and allows unconstrained alteration of the set 
contents by an attacker, defeating the whole point of secure coding.  It 
suggests to me that having arbitrary collection classes claim to implement 
NSSecureCoding would be misleading/wrong.

So presumably I'm missing/misunderstanding something about this.