[PR #2434] [CLOSED] fix(apple): preserve leading U+FEFF in load-command strings #5228

New issue

Closed

opened 2026-10-31 01:04:58 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:04:58 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2434
Author: @Aurantium-47
Created: 10/13/2026
Status: ❌ Closed

Base: main ← Head: fix/macho-leading-feff

📝 Commits (1)

77fe8d8 fix(apple): preserve leading U+FEFF in load-command strings

📊 Changes

3 files changed (+77 additions, -1 deletions)

View changed files

📝 src/artifacts/apple/MachoLoadCommandReader.test.ts (+29 -0)
📝 src/artifacts/apple/MachoLoadCommandReader.ts (+2 -1)
📝 tests/boundary/cli/dylibResolutionCli.test.ts (+46 -0)

📄 Description

Withdrawn as a duplicate of #2110. That earlier PR already applies the same ignoreBOM: true correction to the Mach-O load-command decoder and covers it with parser and CLI regressions. My earlier duplicate check missed it; closing this PR to avoid duplicating the existing work.

Summary

Preserve a leading U+FEFF in Mach-O load-command strings. A dependency spelled \uFEFF@rpath/libcore.dylib was being read as @rpath/libcore.dylib, which could make trace-dylib-resolution report a successful match to a different name.

Problem and expected behavior

TextDecoder removes an initial UTF-8 BOM by default. An lc_str is an embedded NUL-terminated pathname or environment string, so those bytes belong to its value. Apple's format definition requires matching library pathnames. This source-discovered bug has no linked issue; related issues and PRs were checked before implementation.

Change and scope

Set ignoreBOM: true in the existing commandString decoder. The same owner serves dylib IDs and dependencies, rpaths, and embedded dyld environment strings. Fatal UTF-8 validation remains enabled. This is an ordinary static-inspection fix within existing scope; advance maintainer scope approval is not applicable.

Contract and boundary impact

Owner: Mach-O load-command string decoding, before dependency resolution.
CLI/MCP: existing schemas and commands remain unchanged; reported string values retain their original leading character.
Evidence: no renamed dependency or invented successful match; original artifact identity remains unchanged.
Target effects: existing local files are read. No target execution, mutation, network access, provider, packaging, or generated-metadata change.

Evidence and regression coverage

A reader regression covers all five affected command encodings/fields and fails on the base revision; all 26 prior reader tests pass there.
A compiled public CLI regression contrasts both spellings in the same generated Mach-O bundle. With the fix, the prefixed name is retained with undetermined resolution because its runtime-relative base is unknown. The ordinary @rpath name still resolves to Contents/Frameworks/libcore.dylib.

Validation performed

Reader and applicable CLI cases: 36 passed. The host is Windows; two existing cases requiring symlink privileges or POSIX chmod(000) semantics were excluded from that selection.
npm run check — six tasks and architecture guards passed, with no lint errors.
npm run verify:test-discovery — all 1,004 test files discovered exactly once.
git diff --check — passed.

The fixtures exercise REA's actual static CLI, not dyld execution or a disassembler engine. No new real-provider capability is claimed.

Before merge

Focused source fix with failing-before regression and public CLI coverage.
Original bytes, uncertainty, and existing malformed-input behavior preserved.
No contract, generated metadata, package, or migration changes required.
Final diff checked for unrelated changes and credentials.

AI assistance: OpenAI GPT-6 assisted with implementation and verification.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2434 **Author:** [@Aurantium-47](https://github.com/Aurantium-47) **Created:** 10/13/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/macho-leading-feff` --- ### 📝 Commits (1) - [`77fe8d8`](https://github.com/morluto/rea/commit/77fe8d8edcf62ee92dfd5609046be8495faa0469) fix(apple): preserve leading U+FEFF in load-command strings ### 📊 Changes **3 files changed** (+77 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/artifacts/apple/MachoLoadCommandReader.test.ts` (+29 -0) 📝 `src/artifacts/apple/MachoLoadCommandReader.ts` (+2 -1) 📝 `tests/boundary/cli/dylibResolutionCli.test.ts` (+46 -0) </details> ### 📄 Description **Withdrawn as a duplicate of #2110.** That earlier PR already applies the same `ignoreBOM: true` correction to the Mach-O load-command decoder and covers it with parser and CLI regressions. My earlier duplicate check missed it; closing this PR to avoid duplicating the existing work. --- ## Summary Preserve a leading U+FEFF in Mach-O load-command strings. A dependency spelled `\uFEFF@rpath/libcore.dylib` was being read as `@rpath/libcore.dylib`, which could make `trace-dylib-resolution` report a successful match to a different name. ## Problem and expected behavior `TextDecoder` removes an initial UTF-8 BOM by default. An `lc_str` is an embedded NUL-terminated pathname or environment string, so those bytes belong to its value. [Apple's format definition](https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/loader.h#L619-L645) requires matching library pathnames. This source-discovered bug has no linked issue; related issues and PRs were checked before implementation. ## Change and scope Set `ignoreBOM: true` in the existing `commandString` decoder. The same owner serves dylib IDs and dependencies, rpaths, and embedded dyld environment strings. Fatal UTF-8 validation remains enabled. This is an ordinary static-inspection fix within existing scope; advance maintainer scope approval is not applicable. ## Contract and boundary impact - Owner: Mach-O load-command string decoding, before dependency resolution. - CLI/MCP: existing schemas and commands remain unchanged; reported string values retain their original leading character. - Evidence: no renamed dependency or invented successful match; original artifact identity remains unchanged. - Target effects: existing local files are read. No target execution, mutation, network access, provider, packaging, or generated-metadata change. ## Evidence and regression coverage - A reader regression covers all five affected command encodings/fields and fails on the base revision; all 26 prior reader tests pass there. - A compiled public CLI regression contrasts both spellings in the same generated Mach-O bundle. With the fix, the prefixed name is retained with `undetermined` resolution because its runtime-relative base is unknown. The ordinary `@rpath` name still resolves to `Contents/Frameworks/libcore.dylib`. ## Validation performed - Reader and applicable CLI cases: 36 passed. The host is Windows; two existing cases requiring symlink privileges or POSIX `chmod(000)` semantics were excluded from that selection. - `npm run check` — six tasks and architecture guards passed, with no lint errors. - `npm run verify:test-discovery` — all 1,004 test files discovered exactly once. - `git diff --check` — passed. The fixtures exercise REA's actual static CLI, not dyld execution or a disassembler engine. No new real-provider capability is claimed. ## Before merge - [x] Focused source fix with failing-before regression and public CLI coverage. - [x] Original bytes, uncertainty, and existing malformed-input behavior preserved. - [x] No contract, generated metadata, package, or migration changes required. - [x] Final diff checked for unrelated changes and credentials. AI assistance: OpenAI GPT-6 assisted with implementation and verification. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:04:58 +00:00