IDREF not supported

[VisualEhrmanntraut]

Encountered a plist that can't be parsed when <integer /> exists in the file.
Example:

<key>UIDeviceFamily</key><array><integer IDREF="2"/></array>

[ebarnard]

Please can you post the full .plist file that contins the snippet above.

[VisualEhrmanntraut]

@ebarnard It's a prelinked kext info plist
it's kind of weird
Info.plist.zip
EDIT: the XML formatter might've messed it up a bit, it's not how it should look like
the contents of the original are almost exactly the same though

[ebarnard]

I've never seen that before. Apple have a test for it though: https://opensource.apple.com/source/IOKitUser/IOKitUser-376/IOCFSerializeTest.c.auto.html.

Looks like fairly simple backreferences, so should be straightforward to implement in the XML parser.

[ctrlcctrlv]

The tests from Apple contain:

<key>key r1</key>	<ref IDREF="1"/>
<key>key r2</key>	<ref IDREF="2"/>
<key>key r3</key>	<ref IDREF="3"/>
<key>key r4</key>	<ref IDREF="4"/>
<key>key r5</key>	<ref IDREF="5"/>

Not this strange empty integer. Are you sure <integer IDREF="1"/> is valid? I think only <ref/>.

[VisualEhrmanntraut]

The tests from Apple contain:

<key>key r1</key>	<ref IDREF="1"/>
<key>key r2</key>	<ref IDREF="2"/>
<key>key r3</key>	<ref IDREF="3"/>
<key>key r4</key>	<ref IDREF="4"/>
<key>key r5</key>	<ref IDREF="5"/>

Not this strange empty integer. Are you sure <integer IDREF="1"/> is valid? I think only <ref/>.

The plist is from Apple; like I said, it's a pre-linked kernel extension plist
So, if it's wrong, blame Apple, not me.

[ctrlcctrlv]

@ChefKissInc Thanks for confirming that. I had no idea what a prelinked kext info plist was. I use a free OS, it has no plists in its kernel ;-)

[ebarnard]

Interestingly, using Apple's plutil to convert that plist to XML or binary format results in an empty plist:

<?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/>
</plist>

This must be a plist format that is only supported by the MacOS kernel.

What was used to create this plist as it contains some interesting comments: <!-- 🤦 -->? I can't believe Apple's tools would do that.

[VisualEhrmanntraut]

Interestingly, using Apple's plutil to convert that plist to XML or binary format results in an empty plist:

<?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/>
</plist>

This must be a plist format that is only supported by the MacOS kernel.

What was used to create this plist as it contains some interesting comments: <!-- 🤦 -->? I can't believe Apple's tools would do that.

I think the references are XML plist specific
I think the comments were just there but it's been a bit too long and now I don't remember lol

[ebarnard]

I think the references are XML plist specific
They're not supported by Apple's own plutil utility, and presumably therefore not by its plist parsing library.

If you run plutil -convert xml1 example.plist it should convert example.plist to an XML plist. If example.plist is already an XML plist, it reads and re-writes it, possibly re-ordering dictionary keys in the process.

I just realised that Info.plist does not contian an XML or plist header, it just starts with a <dict>. Fixing that and running plutil -convert xml1 example.plist gives the following error:

Info.plist: Property List error: Encountered empty on line 377 / JSON error: JSON text did not start with array or object and option to allow fragments not set. around line 1, column 0.

where line 377 contains <integer IDREF="2" />.

There's some more information about this unusual plist format here. Among other things, these plists don't contain a plist header or footer and just start with a plain <dict> tag.

[VisualEhrmanntraut]

and option to allow fragments not set.

Maybe this is it?

[ctrlcctrlv]

Among other things, these plists don't contain a plist header or footer and just start with a plain tag.

• Should be fixable via the patch which closed XmlWriteOptions should allow users to specify the root element they expect (consumer-specified plist root) #80: Support writing a plist without the XML prolog and root element #84.