Repository navigation
plistlib doesn't handle poorly-formatted plists #84561
Description
| BPO | 40381 |
|---|---|
| Nosy | @ronaldoussoren, @ned-deily, @ccaviness |
| Files |
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:
assignee = None
closed_at = None
created_at = <Date 2020-04-24.19:52:32.354>
labels = ['3.7', 'type-bug', 'library']
title = "plistlib doesn't handle poorly-formatted plists"
updated_at = <Date 2020-04-28.10:48:16.471>
user = 'https://github.com/ccaviness'bugs.python.org fields:
activity = <Date 2020-04-28.10:48:16.471>
actor = 'ronaldoussoren'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-04-24.19:52:32.354>
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']
Activity
ccaviness commentedon Apr 24, 2020
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.
ccaviness commentedon Apr 24, 2020
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 commentedon Apr 27, 2020
IMHO this is a bug and plistlib should behave the same as Apple’s libraries here.
richfromm commentedon Sep 18, 2024
See related issues:
#54942
#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)