Re: NSSecureCoding & NSAttributedString
Re: NSSecureCoding & NSAttributedString
- Subject: Re: NSSecureCoding & NSAttributedString
- From: Markus Spoettl <email@hidden>
- Date: Sat, 17 Feb 2018 22:37:02 +0100
On 2/16/18 23:58, Quincey Morris wrote:
On Feb 16, 2018, at 14:13 , Markus Spoettl <email@hidden> wrote:
how can I go about decoding NSAttributedString
I just tried in a playground, and the problem is in NSParagraphStyle, not
NSAttributedString. It looks like it falls foul of the known secure coding
issue about
decoding arrays of unknown type. (NSTextTab is the only class that lives in an
array
within a paragraph style.)
That means NSParagraphStyle doesn’t actually conform to NSSecureCoding, and
therefore
nor does NSAttributedString, when any non-default tabs are present. It’s not
clear that
there’s an easy workaround. The only thing I can think of is to archive the
text tabs
separately, and somehow re-install them on the relevant paragraph styles after
decoding, but that’s going to be a huge PITA in general.
After digging into this a bit further it seems clear to me that there is no solution. It's
is not even possible to ignore attributed strings that contain stuff incomprehensible to
the secure decoder because the decoder stops working after it hit an exception for an
class violation. If your attributed string is at the very end of the decoding process that
might work, but if not, your f'd. There is no delegate call to exchange classes or
content, to ignore the problem or other way to recover, it just blows up.
Somebody didn't think this through it seems. Alternatively, I'm just unable to see the
solution, which I would prefer...
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