On 2/19/18 18:56, Quincey Morris wrote:
On Feb 19, 2018, at 01:42 , Markus Spoettl <ms_li...@shiftoption.com
<mailto: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.)
Yikes? Not really! IMHO it's actually elegant and uses only mechanisms that are available
publicly and for the exact purpose of replacing classes. I just provide a "better" version
of the classes that don't conform to NSSecureCoding which can be use as an stand-in in a
safe way. The sub-classes conform to everything the base classes do + secure coding, so
the NSAttributedString will be intact.
I don't think THAT is the problem with the approach. It's the uncertainty that I catch all
cases that will be thrown at me. Given the extensive list of NSAccessibility.. keys many
of which use (id) as value, the risk is high that it will blow up.
So, while not complete, I think that's an elegant fix, but unusable nonetheless.
Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
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
