[GH-ISSUE #4294] [Bug] inspect_plist reports OpenStep property lists as xml #1696

New issue

Closed

opened 2026-10-16 21:09:12 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:09:12 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4294

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

inspect_plist reports format: "xml" for an OpenStep (old-style ASCII) property list. The decoded values are correct. Only the informational format label names the wrong serialization. The label comes from a regular expression over file -b output that maps any output containing "text" to xml, and file -b describes an OpenStep plist as ASCII text.

Observed on the release build. Every command exited 0:

Input	`file -b`	REA `format`	REA value
`openstep.plist`	`ASCII text`	`xml`	`{"Items":["a","b"],"Name":"Example"}` (correct)
`openstep-data.plist`	`ASCII text`	`xml`	correct, `Blob` as `{"$plist_type":"data","base64":"3q2+7w=="}`
`xml.plist` (control)	`XML 1.0 document text, ASCII text`	`xml`	correct
`binary.plist` (control)	`Apple binary property list`	`binary`	correct

For openstep-data.plist, REA adds the limitation "plutil cannot express this plist as JSON, so it was decoded from plutil's XML conversion". That describes REA's decoding route, not the source format. A UTF-16 XML copy (file -b: XML 1.0 document text, Unicode text, UTF-16, big-endian text) was also correctly reported as xml. Repeated runs gave the same results.

Reproduction

Use the release build stated under Runtime and platform. inspect-plist needs a target, so a copy of /bin/ls serves as one, and each plist is selected with an absolute --relative-path:

mkdir -p /tmp/rea-bug03 && cd /tmp/rea-bug03
cp /bin/ls ./target
printf '{ Name = Example; Items = (a, b); }\n' > openstep.plist
printf '{\n  "Name" = "Example";\n  "Count" = 3;\n  "Blob" = <deadbeef>;\n}\n' > openstep-data.plist
plutil -convert xml1 -o xml.plist openstep.plist
plutil -convert binary1 -o binary.plist openstep.plist
file -b openstep.plist openstep-data.plist xml.plist binary.plist
for f in openstep.plist openstep-data.plist xml.plist binary.plist; do npx -y rea-agents@6.5.0 inspect-plist ./target --relative-path "$PWD/$f" --json; done

Expected behavior

Apple's PropertyListSerialization.PropertyListFormat defines three serialization formats: openStep ("the ASCII property list format inherited from the OpenStep APIs"), xml and binary. An OpenStep file is not XML. REA's inspect_plist result schema allows format to be xml, binary, json or unknown. An OpenStep input should therefore not be reported as xml. It should get a distinct value or unknown, with any limitation REA needs.

Impact and scope

The format label for OpenStep plists is wrong. It is an informational field, every decoded value is correct, and no data is lost.

Workaround: Running file -b on the plist, or checking for a leading <?xml or bplist, identifies the real serialization.

REA version

6.5.0 (tag rea-agents-6.5.0; format classifier unchanged on main)

Runtime and platform

REA: rea-agents 6.5.0 from npm (--version prints 6.5.0), release tag rea-agents-6.5.0 at commit 3b79af28e80785afce9f5998d8f03289402a1847. Main at d52a488 leaves the format classifier and schema unchanged. Its NativeMacOSProvider.ts changes touch only plist path resolution.
Host: macOS 27.0.1 (26A434) arm64, system file and plutil, Node.js v26.10.0.

Target and artifact context

copy of /bin/ls as the active target; self-built OpenStep, XML and binary plist files selected by absolute path

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

Expected source: Apple's PropertyListSerialization.PropertyListFormat reference (cited above) and REA's result schema at the release tag, format: z.enum(["xml", "binary", "json", "unknown"]) (nativeInspection.ts L163).
Failure source: rea inspect-plist ./target --relative-path <file> --json on the release build returns format: "xml" for both OpenStep files. The classifier runs file -b (NativeMacOSProvider.ts L772-L773) and maps /XML|text/ to xml (L820-L824).
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

This investigator ran the commands above on the release build.

Typed outcome or recovery expected

With the inputs above, openstep.plist and openstep-data.plist must no longer be reported as format: "xml". Either an OpenStep-specific value or unknown restores the contract. Their decoded values must stay as they are now. Discriminating controls: xml.plist stays xml, binary.plist stays binary, and a UTF-16 XML plist (iconv -f UTF-8 -t UTF-16 xml.plist > xml16.plist) stays xml.

Analysis or suspected cause

No response

Additional context

Observation, not part of this defect: a JSON file (printf '{"Name":"Example","Count":3}\n' > json.plist, file -b: JSON data) is decoded correctly but reported as format: "unknown", and no code path emits the schema's json value. plutil -lint rejects that file ("Unexpected character {"), while plutil -p reads it. Whether json should be reported is for the maintainers to decide.
No related open issue was found. #3892 and PR #4105 concern __proto__ keys in OpenStep keyed archives, not the reported format.

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4294 ### Before submitting - [X] I searched the open and closed issues for a related report. - [X] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `inspect_plist` reports `format: "xml"` for an OpenStep (old-style ASCII) property list. The decoded values are correct. Only the informational `format` label names the wrong serialization. The label comes from a regular expression over `file -b` output that maps any output containing "text" to `xml`, and `file -b` describes an OpenStep plist as `ASCII text`. Observed on the release build. Every command exited 0: | Input | `file -b` | REA `format` | REA value | |---|---|---|---| | `openstep.plist` | `ASCII text` | `xml` | `{"Items":["a","b"],"Name":"Example"}` (correct) | | `openstep-data.plist` | `ASCII text` | `xml` | correct, `Blob` as `{"$plist_type":"data","base64":"3q2+7w=="}` | | `xml.plist` (control) | `XML 1.0 document text, ASCII text` | `xml` | correct | | `binary.plist` (control) | `Apple binary property list` | `binary` | correct | For `openstep-data.plist`, REA adds the limitation "plutil cannot express this plist as JSON, so it was decoded from plutil's XML conversion". That describes REA's decoding route, not the source format. A UTF-16 XML copy (`file -b`: `XML 1.0 document text, Unicode text, UTF-16, big-endian text`) was also correctly reported as `xml`. Repeated runs gave the same results. ### Reproduction Use the release build stated under Runtime and platform. `inspect-plist` needs a target, so a copy of `/bin/ls` serves as one, and each plist is selected with an absolute `--relative-path`: ```sh mkdir -p /tmp/rea-bug03 && cd /tmp/rea-bug03 cp /bin/ls ./target printf '{ Name = Example; Items = (a, b); }\n' > openstep.plist printf '{\n "Name" = "Example";\n "Count" = 3;\n "Blob" = <deadbeef>;\n}\n' > openstep-data.plist plutil -convert xml1 -o xml.plist openstep.plist plutil -convert binary1 -o binary.plist openstep.plist file -b openstep.plist openstep-data.plist xml.plist binary.plist for f in openstep.plist openstep-data.plist xml.plist binary.plist; do npx -y rea-agents@6.5.0 inspect-plist ./target --relative-path "$PWD/$f" --json; done ``` ### Expected behavior Apple's [PropertyListSerialization.PropertyListFormat](https://developer.apple.com/documentation/foundation/propertylistserialization/propertylistformat) defines three serialization formats: `openStep` ("the ASCII property list format inherited from the OpenStep APIs"), `xml` and `binary`. An OpenStep file is not XML. REA's `inspect_plist` result schema allows `format` to be `xml`, `binary`, `json` or `unknown`. An OpenStep input should therefore not be reported as `xml`. It should get a distinct value or `unknown`, with any limitation REA needs. ### Impact and scope The `format` label for OpenStep plists is wrong. It is an informational field, every decoded value is correct, and no data is lost. Workaround: Running `file -b` on the plist, or checking for a leading `<?xml` or `bplist`, identifies the real serialization. ### REA version 6.5.0 (tag `rea-agents-6.5.0`; format classifier unchanged on main) ### Runtime and platform - REA: `rea-agents` 6.5.0 from npm (`--version` prints `6.5.0`), release tag `rea-agents-6.5.0` at commit `3b79af28e80785afce9f5998d8f03289402a1847`. Main at `d52a488` leaves the format classifier and schema unchanged. Its `NativeMacOSProvider.ts` changes touch only plist path resolution. - Host: macOS 27.0.1 (26A434) arm64, system `file` and `plutil`, Node.js v26.10.0. ### Target and artifact context copy of `/bin/ls` as the active target; self-built OpenStep, XML and binary plist files selected by absolute path ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence - Expected source: Apple's PropertyListSerialization.PropertyListFormat reference (cited above) and REA's result schema at the release tag, `format: z.enum(["xml", "binary", "json", "unknown"])` ([nativeInspection.ts L163](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/native/nativeInspection.ts#L163)). - Failure source: `rea inspect-plist ./target --relative-path <file> --json` on the release build returns `format: "xml"` for both OpenStep files. The classifier runs `file -b` ([NativeMacOSProvider.ts L772-L773](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/native/NativeMacOSProvider.ts#L772-L773)) and maps `/XML|text/` to `xml` ([L820-L824](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/native/NativeMacOSProvider.ts#L820-L824)). - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete This investigator ran the commands above on the release build. ### Typed outcome or recovery expected With the inputs above, `openstep.plist` and `openstep-data.plist` must no longer be reported as `format: "xml"`. Either an OpenStep-specific value or `unknown` restores the contract. Their decoded values must stay as they are now. Discriminating controls: `xml.plist` stays `xml`, `binary.plist` stays `binary`, and a UTF-16 XML plist (`iconv -f UTF-8 -t UTF-16 xml.plist > xml16.plist`) stays `xml`. ### Analysis or suspected cause _No response_ ### Additional context - Observation, not part of this defect: a JSON file (`printf '{"Name":"Example","Count":3}\n' > json.plist`, `file -b`: `JSON data`) is decoded correctly but reported as `format: "unknown"`, and no code path emits the schema's `json` value. `plutil -lint` rejects that file ("Unexpected character {"), while `plutil -p` reads it. Whether `json` should be reported is for the maintainers to decide. - No related open issue was found. #3892 and PR #4105 concern `__proto__` keys in OpenStep keyed archives, not the reported format.

bsakaguchi closed this issue

2026-10-17 21:02:59 +00:00

bsakaguchi referenced this issue

2026-10-31 00:54:48 +00:00

[PR #1696] [CLOSED] docs(contributing): explain the first contribution workflow #4763