plistlib doesn't handle poorly-formatted plists

[d0fb34d0-7f9d-4afd-b049-a5bec6db5ef6]

BPO	40381
Nosy	@ronaldoussoren, @ned-deily, @ccaviness
Files	Info.plist

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['3.7', 'type-bug', 'library'] title = "plistlib doesn't handle poorly-formatted plists" updated_at = user = 'https://github.com/ccaviness' ``` bugs.python.org fields: ```python activity = actor = 'ronaldoussoren' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'Clay Caviness' dependencies = [] files = ['49091'] hgrepos = [] issue_num = 40381 keywords = [] message_count = 3.0 messages = ['367217', '367218', '367447'] nosy_count = 3.0 nosy_names = ['ronaldoussoren', 'ned.deily', 'Clay Caviness'] pr_nums = [] priority = 'normal' resolution = None stage = 'needs patch' status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue40381' versions = ['Python 3.7'] ```

[d0fb34d0-7f9d-4afd-b049-a5bec6db5ef6]

Some Info.plist files are poorly formatted. I am using plistlib to read Info.plist file from various .app bundles. On some, plistlib.load raises a ValueError when trying to parse.

Examining one of these Info.plist files, it turns out *it* is poorly formatted, but while python's plistlib is unhappy, it passes "plutil -lint" just fine and "Foundation.NSDictionary.dictionaryWithContentsOfFile_" is happy to read it.

Here's a minimal sample plist file: """ \<?xml version="1.0" encoding="UTF-8"?> \<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> \<plist version="1.0"> \<dict> \<key>An array\</key> \<array> \<string>a string\</string> \<key>A wild key appears!\</key> \<string>it has a string\</string> \<string>another string\</string> \</array> \</dict> \</plist> """

plistlib (correctly, I think) says that's no good. Apple's tooling just ... changes the key to another string in the array and carries on.

I've attached an actual problematic Info.plist as well.

[d0fb34d0-7f9d-4afd-b049-a5bec6db5ef6]

I expect the answer here to be "plistlib is correct, that's a poorly formatted plist", but since plistlib is "for reading and writing the “property list” files used mainly by Mac OS X and supports both binary and XML plist files", and Apple's own tooling handles these poorly-formatted files without error it was worth raising the issue.

[ronaldoussoren]

IMHO this is a bug and plistlib should behave the same as Apple’s libraries here.

[richfromm]

See related issues: https://github.com/python/cpython/issues/54942 https://github.com/python/cpython/issues/95722

I suspect the answer will be the same, that plistlib shouldn't support what is essentially buggy behavior by Apple (generating and?) parsing improperly formatted XML with their tooling.

Personally, I think that even if this were the default behavior, it would be great if there was an option to be more permissive and compatible with Apple tooling. But I can understand the reluctance of embedding that kind of thing in the Python stdlib. (esp. since the behavior of Apple's tools could change at any time, with no warning, and no documentation)