[GH-ISSUE #8661] [Bug] OpenStep quoted escapes make existing app executables appear missing #7503

New issue

Closed

opened 2026-11-03 00:30:18 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 00:30:18 +00:00

Owner

Originally created by @xu91102 on GitHub (Nov 2, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8661

Observed failure

On macOS arm64 with Node.js 24.22.1 and freshly built main 93b8b82db70279e40f484114cff9dc1958dc14ee, a valid old-style/OpenStep Info.plist can make the public list-architectures command report that the bundle executable is missing even though it exists.

I compiled an owned minimal Mach-O (int main(void) { return 0; }) with xcrun clang and placed the identical bytes at Probe.app/Contents/MacOS/Main. The target was never executed. Changing only Contents/Info.plist gives:

{ CFBundleExecutable = "Main"; }          -> exit 0, arm64
{ CFBundleExecutable = "M\U0061in"; }     -> exit 1, looks for MU0061in
{ CFBundleExecutable = "M\141in"; }       -> exit 1, looks for M141in
{ "CFBundle\U0045xecutable" = "Main"; }  -> exit 1, CFBundleExecutable missing

Command: node scripts/rea.mjs list-architectures /absolute/path/Probe.app --format json.

For all four inputs /usr/bin/plutil -convert json -o - Info.plist resolves the same CFBundleExecutable: Main. A separate genuinely missing executable remains correctly refused. Source plist and executable bytes are unchanged after inspection. inspect-plist succeeds on these same bundles through its native conversion path, making the inconsistency especially confusing.

Expected behavior and producing boundary

Supported OpenStep quoted keys and values should have the same escape interpretation when resolving bundles as when reading their plist. The shared decodeOpenStepPropertyList currently delegates quoted scalar tokens to the pinned plist decoder, which drops the backslash instead of decoding Unicode/octal escapes. An additional isolated comparison found "\U00e9" becomes U00e9 rather than é. Octal bytes use NeXTSTEP encoding in Foundation, rather than UTF-8 or Latin-1, so a fix needs to preserve that distinction.

Primary reference: CoreFoundation quoted escape reader.

Scope and limits

This report concerns existing static OpenStep decoding and App bundle resolution, not launching applications or adding a provider. Related actual patches #4105, #4047, #7999, #8057 and #8115 address other boundaries; #8525 does not change this quoted scalar owner. I did not run those foreign heads. Real-world prevalence, other hosts and full engine workflows are NOT_RUN. No proposed implementation has been made yet.

Originally created by @xu91102 on GitHub (Nov 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8661 ### Observed failure On macOS arm64 with Node.js 24.22.1 and freshly built main `93b8b82db70279e40f484114cff9dc1958dc14ee`, a valid old-style/OpenStep `Info.plist` can make the public `list-architectures` command report that the bundle executable is missing even though it exists. I compiled an owned minimal Mach-O (`int main(void) { return 0; }`) with `xcrun clang` and placed the identical bytes at `Probe.app/Contents/MacOS/Main`. The target was never executed. Changing only `Contents/Info.plist` gives: ```text { CFBundleExecutable = "Main"; } -> exit 0, arm64 { CFBundleExecutable = "M\U0061in"; } -> exit 1, looks for MU0061in { CFBundleExecutable = "M\141in"; } -> exit 1, looks for M141in { "CFBundle\U0045xecutable" = "Main"; } -> exit 1, CFBundleExecutable missing ``` Command: `node scripts/rea.mjs list-architectures /absolute/path/Probe.app --format json`. For all four inputs `/usr/bin/plutil -convert json -o - Info.plist` resolves the same `CFBundleExecutable: Main`. A separate genuinely missing executable remains correctly refused. Source plist and executable bytes are unchanged after inspection. `inspect-plist` succeeds on these same bundles through its native conversion path, making the inconsistency especially confusing. ### Expected behavior and producing boundary Supported OpenStep quoted keys and values should have the same escape interpretation when resolving bundles as when reading their plist. The shared `decodeOpenStepPropertyList` currently delegates quoted scalar tokens to the pinned `plist` decoder, which drops the backslash instead of decoding Unicode/octal escapes. An additional isolated comparison found `"\U00e9"` becomes `U00e9` rather than `é`. Octal bytes use NeXTSTEP encoding in Foundation, rather than UTF-8 or Latin-1, so a fix needs to preserve that distinction. Primary reference: [CoreFoundation quoted escape reader](https://github.com/swiftlang/swift-corelibs-foundation/blob/main/Sources/CoreFoundation/CFOldStylePList.c). ### Scope and limits This report concerns existing static OpenStep decoding and App bundle resolution, not launching applications or adding a provider. Related actual patches #4105, #4047, #7999, #8057 and #8115 address other boundaries; #8525 does not change this quoted scalar owner. I did not run those foreign heads. Real-world prevalence, other hosts and full engine workflows are NOT_RUN. No proposed implementation has been made yet.

bsakaguchi closed this issue

2026-11-03 15:31:06 +00:00

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#7503

No description provided.

Rows
Columns