• 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: Feeding NSUnarchiver bad data can cause crash
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feeding NSUnarchiver bad data can cause crash


  • Subject: Re: Feeding NSUnarchiver bad data can cause crash
  • From: Glenn Andreas <email@hidden>
  • Date: Thu, 3 Jun 2004 11:27:50 -0500

At 5:05 PM +0100 6/3/04, Jeremy Dronfield wrote:
On 3 Jun 2004, at 3:02 pm, Ian Clark wrote:
The setup I'm using is this. An attributed string is archived, and the archived data is encrypted using a Blowfish symmetric cipher, producing a second data object which is saved to disk. Later, the encrypted data is decrypted. If the key used for decryption is the wrong one, the data will decrypt, but will be "bad" data.


Why not just add your own tag to the start of the data before you encrypt it. When you decrypt it, check for the tag (to see if it decoded correctly), and then remove that tag and decode it.

In general, the "is this encoded stream valid" isn't answerable - at best the encoding mechanism could tell if it things that structure of the data is potentially valid. Since every object can have it's own encoding (what is encode, what order, etc...) you may end up with a value that is the correct "structure" but whose contents are bogus (so the structure may say "here is an integer" but the object wants to decode a float). This sort of logic would need to be implemented in every object that can be encoded - including all of your objects. Even worse would be the ones where the value is the correct structure and format, but may be a value that is out of range (or if you had a float, what if the result is "NaN" - is that valid for this field of the given object?).

Even just checking "is this structure valid" isn't all that useful - if it returns NO, you know you've got problems, great, you can deal with them. If it returns YES, well, you can still have problems (as discussed above) and it can still crash, so you haven't gained a whole lot. Tests that return false positives (or negatives) are rarely useful outside of debugging sanity checks.

--
Glenn Andreas email@hidden mondo blobbo, Cythera, Theldrow, oh my!
Mad, Bad, and Dangerous to Know
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: Feeding NSUnarchiver bad data can cause crash
      • From: Jeremy Dronfield <email@hidden>
References: 
 >Re: Feeding NSUnarchiver bad data can cause crash (From: Jeremy Dronfield <email@hidden>)

  • Prev by Date: Re: NSObjectController HELP
  • Next by Date: Re: function pointer in Cocoa
  • Previous by thread: Re: Feeding NSUnarchiver bad data can cause crash
  • Next by thread: Re: Feeding NSUnarchiver bad data can cause crash
  • Index(es):
    • Date
    • Thread