plistlib in Python 3.7.3 (and earlier) does not autodetect plist data as XML if it contains whitespace before the "<?xml" tag.  Apple tools (and code) however, do.

Suggestion:  lstrip() the header bytes before comparison

Source Link: https://github.com/python/cpython/blob/3.7/Lib/plistlib.py#L493

Thanks for the report.  Would you be interested in providing a pull request with a fix?

I don't agree with calling lstrip() before checking which format is used because leading whitespace is invalid for binary plist files (and plutil agrees with me on that).

lstrip() would not work with UTF-16 encoded plist files neither with BOM.

Who produces plist files with leading whitespaces?

@shaneg, could you elaborate on why you created this issue?

I don't know of tooling that would generate such files, and it is highly unlikely that Apple's system tooling/libraries would do so.

This issue was created because I ran across a plist like this when parsing entitlements in an IPA.  I assume that this happened by some unusual step in the toolchain when building the application.

To some other points:
* agreed lstrip()ing just the key would not work (unfortunately I suggested this before actually coding up a workaround for my case).
* agreed that binary plists should not have any stripping.
* I have not tried testing apple tools (e.g. plutil) against XML plists with BOMs before any leading whitespace.

You can always strip the file yourself :-)

Ignoring leading whitespace for XML would be fairly invasive due to the way the code is set up. I'm not set against it, but I'm not in favour of complicating the implementation for an edge case like this.