Description

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'

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

1. ccaviness commented on Apr 24, 2020

   

   ccavinessmannequin

   on Apr 24, 2020

   MannequinAuthor

   More actions

   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.
2. ccaviness

   added

   3.7 (EOL)end of lifeend of life

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   on Apr 24, 2020
3. ccaviness commented on Apr 24, 2020

   

   ccavinessmannequin

   on Apr 24, 2020

   MannequinAuthor

   More actions

   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.
4. ronaldoussoren commented on Apr 27, 2020

   

   ronaldoussoren

   on Apr 27, 2020

   Contributor

   More actions

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

   Reacted by Glyph
5. ronaldoussoren

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Apr 28, 2020
6. ezio-melotti

   transferred this issue fromon Apr 10, 2022
7. richfromm commented on Sep 18, 2024

   

   richfromm

   on Sep 18, 2024

   More actions

   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)
8. StanFromIreland

   removed

   3.7 (EOL)end of lifeend of life

   on Sep 29, 2025

Issue actions