• 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: Alex Zavatone <email@hidden>
  • Date: Sat, 17 Feb 2018 19:27:50 -0600

What about the option mentioned before of converting to another type, RTF, and
handling that?

> On Feb 17, 2018, at 3:37 PM, Markus Spoettl <email@hidden> wrote:
>
> 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

_______________________________________________

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: "Glenn L. Austin" <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>)

  • 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