Plistlib doesn't do much error checking, and it can crash on bad 
input. Moreover, it doesn't provide much help if it does crash (no 
linenumbers, etc).

The problem I ran into was a dangling <key>foo</key>. After this 
key the dict ended, but the next entry in the surrounding 
datastructure, an array, picked up the key from self.currentKey 
and crashed in addObject().

I was about to fix this when I noticed that there's lots of problems 
with <key> handling, duplicates or missing ones aren't detected 
either and can cause crashes too. It may be better to put a general 
try/except in parse() and print a line number or something in case 
of a failure.

The attached patch fixes crashes on bad input. The patch implements validation for dict and array elements as well as some resource cleanup. The tests are included as well.

One review comment: the patch adds a new exception class that is used for the errors that are now additionally detected.  Elsewhere plistlib uses non-specific exception classes like ValueError.  If starting from scratch, it might be better to consistently use a specific exception class but that would create incompatibilities if changed now.  I don't see a compelling need to add one now just for these errors.  (But, if kept, it should be added to the docs.)  Otherwise, looks good to me.

Thanks for taking this on!

I've replaced plistlib.InvalidPlistError with ValueError

LGTM.

See also reopened dependency #775321.

New changeset a2688e252204 by Ned Deily in branch '3.1':
Issue #985064: Make plistlib more resilient to faulty input plists.
http://hg.python.org/cpython/rev/a2688e252204

New changeset f555d959a5d7 by Ned Deily in branch '3.2':
Issue #985064: Make plistlib more resilient to faulty input plists.
http://hg.python.org/cpython/rev/f555d959a5d7

New changeset d0bc18a50bd1 by Ned Deily in branch 'default':
Issue #985064: Make plistlib more resilient to faulty input plists.
http://hg.python.org/cpython/rev/d0bc18a50bd1

Thank you for the patch and tests!  Applied in 3.1 (for 3.1.4), 3.2 (for 3.2.1), and 3.3. (The 2.x version of plistlib differs somewhat from the 3.x version so the patch would need some rework and testing for 2.7; that is probably not worth the effort at this point.)