• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSSecureCoding & NSAttributedString
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSecureCoding & NSAttributedString


  • Subject: Re: NSSecureCoding & NSAttributedString
  • From: Markus Spoettl <email@hidden>
  • Date: Mon, 19 Feb 2018 19:32:03 +0100

On 2/19/18 18:56, Quincey Morris wrote:
On Feb 19, 2018, at 01:42 , Markus Spoettl <email@hidden <mailto: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.)

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 (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

  • Follow-Ups:
    • Re: NSSecureCoding & NSAttributedString
      • From: Quincey Morris <email@hidden>
References: 
 >NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Alex Zavatone <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: "Glenn L. Austin" <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Markus Spoettl <email@hidden>)
 >Re: NSSecureCoding & NSAttributedString (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: NSSecureCoding & NSAttributedString
  • Next by Date: Re: NSSecureCoding & NSAttributedString
  • Previous by thread: Re: NSSecureCoding & NSAttributedString
  • Next by thread: Re: NSSecureCoding & NSAttributedString
  • Index(es):
    • Date
    • Thread