Re: NSSecureCoding & NSAttributedString
Re: NSSecureCoding & NSAttributedString
- Subject: Re: NSSecureCoding & NSAttributedString
- From: Quincey Morris <email@hidden>
- Date: Mon, 19 Feb 2018 09:56:06 -0800
On Feb 19, 2018, at 01:42 , Markus Spoettl <email@hidden> 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 (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