On Feb 19, 2018, at 01:42 , Markus Spoettl <ms_li...@shiftoption.com> wrote:
> I'm not sure where the NSAccessibility… keys are defined


> I found a workaround for the problem for classes that are not NSSecureCoding 
> compliant:
> First I sub-class the offending class, implementing the NSSecureCoding 
> protocol, […].
> Then I set up the class as substitution for the original in the 
> NSKeyedUnarchiver using -setClass:forClassName:.

Yikes! So you hack the unarchiving process to substitute a malfunction class 
for the real one, in order to protect the unarchiving process from being 
hacked? Is this really safer than not using secure coding at all? (That’s a 
genuine question. Maybe this *does* plug the hole.)

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:

This email sent to arch...@mail-archive.com

Reply via email to