Re: NSSecureCoding & NSAttributedString
Re: NSSecureCoding & NSAttributedString
- Subject: Re: NSSecureCoding & NSAttributedString
- From: Markus Spoettl <email@hidden>
- Date: Mon, 19 Feb 2018 10:42:37 +0100
On 2/18/18 23:26, Quincey Morris wrote:
I dunno. I always though of the attributes as something extensible, but I guess they’re
not really. (They can’t be, in NSAttributedString is an interchange format between apps.)
Looking at the documented list, I would be worried about NSTextAttachment, which isn’t
even documented as conforming to NSSecureCoding. Those NSAccessibility… keys don’t look
too safe either.
I'm not sure where the NSAccessibility… keys are defined, I looked at NSAttributedString.h
they are not there. Anyway...
The saga isn't over yet, 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,
+supportsSecureCoding and -initWithCoder:. Since it is impossible to safely invoke the
non-secure -initWithCoder: version of the class itself, I use a suitable other designated
initializer when calling super.
Then I set up the class as substitution for the original in the NSKeyedUnarchiver using
-setClass:forClassName:.
Finally I add it to the list of acceptable classes when decoding the attributed
string.
Works fine for NSShadow, NSTextAttachment and NSCursor.
Of course this looses the attributes real values, but those I don't care about
anyway.
I haven't encountered a cursor attribute yet, though.
Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
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