On Feb 19, 2018, at 01:42 , Markus Spoettl <ms_li...@shiftoption.com> wrote:
>
> I'm not sure where the NSAccessibility… keys are defined
https://developer.apple.com/documentation/foundation/nsattributedstringkey
> 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
