[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 9 Nov 2019 16:11:34 +0100
> Am 09.11.2019 um 13:39 schrieb Richard Frith-Macdonald <address@hidden>:
>> On 9 Nov 2019, at 11:40, Gregory Casamento <address@hidden> 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.
I think you are misled by the term “secure” here. As far as I understand the
(limited) documentation, all that “secure coding” attempts to achieve is that
it gives you some added type safety, so that, for instance, if you encode a
NSWindow on one side, send it across the wire, and then attempt to decode it
as, say, an NSView on the other side you’ll get an error rather than some
garbage. It doesn’t look like it is an attempt to prevent attacks on the
contents of an archive, which presumably would be better addressed at the level
of the archive as a whole (for instance by adding a cryptographic signature to
the archive) than at the level of individual objects.
With that in mind, collection classes can trivially support secure coding
because (ignoring generics) they do not make any constraints on their elements,
so your code has to (or at least should) deal with arbitrary objects here