Playing with https://github.com/kolide/launcher/ I'm getting reports that launchd seems to require self closing xml tags for booleans.

I notice that this library used support this (c271b43), but that it was reverted in 4dc2eea

The other plist library seems to have fixed this with a dedicated xml encoder -- DHowett/go-plist#34

There's an underlying go xml issue for this as well -- golang/go#21399

I'm a bit confused about how to use/implement UnmarshalPlist. What am I meant to pass to the function func (i interface{}) error? When I pass the struct, I get an infinite loop.

My use case is I'm trying to unmarshal an iOS Workflow plist, but I'm stuck on the key WFTextActionText that can either be <string> or <dict>. I thought I could implement UnmarshalPlist on the struct that holds WFTextActionText to determine whether to set a WFTextActionTextString or WFTextActionTextDict value.

Thanks in advanced =)

Example plist and Go file: https://gist.github.com/henrahmagix/7b8909a02dcd326aa29dcd46be1dd8c6

Example string:

<key>WFTextActionText</key>
<string>City 1, state 1,country 1</string>

Example dict:

<key>WFTextActionText</key>
<dict>
	<key>Value</key>
	<dict>
		<key>attachmentsByRange</key>
		<dict>
			<key>{13, 1}</key>
			<dict>
				<key>Type</key>
				<string>Variable</string>
				<key>VariableName</key>
				<string>State</string>
			</dict>
			<key>{23, 1}</key>
			<dict>
				<key>Type</key>
				<string>Variable</string>
				<key>VariableName</key>
				<string>Country</string>
			</dict>
			<key>{5, 1}</key>
			<dict>
				<key>Type</key>
				<string>Variable</string>
				<key>VariableName</key>
				<string>City</string>
			</dict>
		</dict>
		<key>string</key>
		<string>City= State= Country=</string>
	</dict>
	<key>WFSerializationType</key>
	<string>WFTextTokenString</string>
</dict>

A plist that begins with this:

<?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">
test
<plist version="1.0">
<dict>
	<key>PayloadContent</key>

.. is successfully parsed. Note the test after the docstring. While apparently valid XML definitely not a valid plist.

I have an issue with plist files that macOS keeps in Preferences folder, and after some debugging I found that decoder does not respect possibility of the floating point number to be 4 bytes long.

What I get: unexpected EOF returned by parseReal, specifically from this line:

The length of the byte slice there is 4 bytes, but binary.Read expects 8 bytes for float64 type.

This can probably be fixed with byte length check and with float32 type in case the length is 4. Then, it can be safely converted to float64 for internal use.

I noticed that converting problematic files to xml and back to binary solves the issue: plist encodes new binary files with float64 bytes, however, this is not a suitable workaround for me.

Thanks for a great package!

I end up needing to have an external func to automatically decode a binary or XML plist, see below.

It would be nice to replace the deprecated plist.NewDecoder func with this. Happy to provide a PR on your suggestion.

// NewPListDecoder returns a new Property List decoder, auto-detecting
// whether it is binary or XML text.
func NewPListDecoder(r io.ReadSeeker) *plist.Decoder {
	// Detect if it XML or Binary
	magic := make([]byte, 5)
	n, err := r.Read(magic)
	if err != nil {
		return nil
	}
	_, err = r.Seek(0, 0)
	if err != nil {
		return nil
	}
	switch string(magic[:n]) {
	case "<?xml":
		return plist.NewXMLDecoder(r)
	case "bplis":
		return plist.NewBinaryDecoder(r)
	}
	return nil
}

I noticed that when I'm parsing binary plists with a bunch of opaque data, it's often truncated. And this seems unique to binary parsing.

I don't have a test file I can share, but you can see this examining /var/db/dslocal/nodes/Default/users/seph.plist (or similar)

When read directly, it's the binary path and things like LinkedIdentity are truncated. But if it's converted to xml first, the data is correct. This happens when using both plist.Unmarshal and plist.NewBinaryDecoder

I've attached a trivial dump script -- plist-dump.go.zip

A new interface

Currently we have the Unmarshaler interface for this, but it relies on being able to implement that interface on any custom type. When that type exists in another package that we do not have control over, we can't use the interface and instead must unmarshal manually, which is a lot of work.

I would suggest adding an optional callback func in Decoder that can be called when we do not know how to otherwise unmarshal a value:

type UnmarshalUnknownFunc func(
   plistValue interface{},
   marshalType reflect.Type,
) (
   unmarshaledValue interface{},
   ok bool,
   err error,
)

type Decoder struct {
   // existing fields...

   // When a type is unknown during unmarshaling, we call this function when
   // non-nil, to provide the unmarshaled value.  The callback can indicate
   // that the value cannot be unmarshaled, in which case it is skipped.
   OnUnmarshalUnsupported UnmarshalUnknownFunc
}

This would obviously require users to use New{XML,Binary}Decoder to be able to set this callback func, over using Unmarshal directly.

Furthermore, it would allow unknown types to be "skipped", when ok is false. Currently we just fail with an error.

Improving the existing interface

Separately, the current interface is a little awkward with the argument being a function, as seen in #14. A more straightforward interface might instead be:

type Unmarshaler interface {
   UnmarshalPlist(plistValue interface{}) (unmarshaledValue interface{}, err error)
}

The binary plist tries to allocate a slice of arbitrary size and if it fails it tries to recover. But that doesn't actually work.

Setting 4<<20 (4 * 1024 * 1024) as an arbitrary limit until the binary parser is updated with better logic.

Should we return an explicit error is byte slice is too small for this check?

so many yaks to shave.

Support field tag "-" to signify not to do anything with the field. Like encoding/json:

As a special case, if the field tag is "-", the field is always omitted.