[GH-ISSUE #2129] [Bug] Binary plists are rejected as targets unless the file name ends in .plist #694

Closed
opened 2026-10-15 18:27:28 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @kaoru0822-kitauji on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2129

Observed behavior

A binary property list is admitted as a target only when its name ends in .plist. The same bytes under another extension are rejected before any plist tool runs:

$ rea inspect-keyed-archive /Applications/iMovie.app/Contents/Frameworks/TextFramework.framework/Versions/A/Resources/TextStylePreviewCache.archive --format json
{"code":"target_unavailable","message":"Cannot open artifact: unsupported binary format.", "details":{"reason":"unsupported binary format","constraint":"file_format_rejected", ...}}

$ cp …/TextStylePreviewCache.archive /tmp/ka.plist && rea inspect-keyed-archive /tmp/ka.plist --format json
{"evidence_id":"ev_…","subject":{"format":"plist",…}, …}   # succeeds

file reports "Apple binary property list" (bplist00 magic), and plutil -p shows an NSKeyedArchiver archive. The command's help describes path as a "Foundation plist archive or Apple app bundle". Keyed archives commonly use other extensions (.archive, .data, .nib, app-specific names).

Reproduction

Any bplist00 file whose name does not end in .plist (current main c22111eca). The iMovie file above is one real example; plutil -convert binary1 -o x.archive some.plist makes another.

Expected behavior

Recognize a binary plist by its bplist00 magic, as the artifact inventory already does (classifyArtifactBytes in src/artifacts/inventory/ArtifactGraphConstruction.ts returns plist for that prefix regardless of name).

Cause

detectArtifactFormat in src/application/BinaryTargetResolver.ts reads the first 8 bytes but classifies plists only through namedArtifactFormat, which checks lowerPath.endsWith(".plist").

Originally created by @kaoru0822-kitauji on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2129 ### Observed behavior A binary property list is admitted as a target only when its name ends in `.plist`. The same bytes under another extension are rejected before any plist tool runs: ```text $ rea inspect-keyed-archive /Applications/iMovie.app/Contents/Frameworks/TextFramework.framework/Versions/A/Resources/TextStylePreviewCache.archive --format json {"code":"target_unavailable","message":"Cannot open artifact: unsupported binary format.", "details":{"reason":"unsupported binary format","constraint":"file_format_rejected", ...}} $ cp …/TextStylePreviewCache.archive /tmp/ka.plist && rea inspect-keyed-archive /tmp/ka.plist --format json {"evidence_id":"ev_…","subject":{"format":"plist",…}, …} # succeeds ``` `file` reports "Apple binary property list" (`bplist00` magic), and `plutil -p` shows an `NSKeyedArchiver` archive. The command's help describes `path` as a "Foundation plist archive or Apple app bundle". Keyed archives commonly use other extensions (`.archive`, `.data`, `.nib`, app-specific names). ### Reproduction Any `bplist00` file whose name does not end in `.plist` (current main c22111eca). The iMovie file above is one real example; `plutil -convert binary1 -o x.archive some.plist` makes another. ### Expected behavior Recognize a binary plist by its `bplist00` magic, as the artifact inventory already does (`classifyArtifactBytes` in `src/artifacts/inventory/ArtifactGraphConstruction.ts` returns `plist` for that prefix regardless of name). ### Cause `detectArtifactFormat` in `src/application/BinaryTargetResolver.ts` reads the first 8 bytes but classifies plists only through `namedArtifactFormat`, which checks `lowerPath.endsWith(".plist")`.
bsakaguchi 2026-10-15 18:27:28 +00:00
  • closed this issue
  • added the
    bug
    label
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#694
No description provided.