Re: NSSecureCoding & NSAttributedString
Re: NSSecureCoding & NSAttributedString
- Subject: Re: NSSecureCoding & NSAttributedString
- From: Markus Spoettl <email@hidden>
- Date: Sun, 18 Feb 2018 19:30:00 +0100
On 2/18/18 06:12, Quincey Morris wrote:
On Feb 17, 2018, at 20:34 , Glenn L. Austin <email@hidden> wrote:
Or encode/decode them using Coding, then encode/decode the resulting encoded
attributed string data using SecureCoding.
Markus already said that archives exist with normally-encoded attributed
strings, so
that precludes changing the archive format in the way you say.
But that does suggest a partial alternative. In the object that decodes the
attributed
string, Markus can turn “usesSecureCoding” off for that decode only (in the
coder
object, which has this property defined). This won’t be secure against attacks
via the
objects *in* the attributed strings, but it would protect the rest of the
archive.
As a security precaution Turning off requiresSecureCoding once it is turned on causes an
exception, so that's not an option.
I have now gotten it to work simply by decoding the attributed string like this:
NSSet *allowed =
[NSSet setWithObjects:[NSAttributedString class], [NSTextTab class], nil];
notes = [[decoder decodeObjectForClasses:allowed] retain];
The decoder isn't terribly concerned with where the individual classes will occur, just
that they might.
Of course that doesn't mean that it will work generally speaking, just for my special
case. I don't mind adding more allowed classes there, any ideas what else I (or rather my
users) might encounter?
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