[PR #4291] [CLOSED] fix(artifacts): accept bare arm64e as lipo reported name for arm64e slice #6162

Closed
opened 2026-10-31 01:12:20 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4291
Author: @dav9fulldev
Created: 10/16/2026
Status: ❌ Closed

Base: main ← Head: fix/macos-arm64e-slice-lipo


📝 Commits (1)

  • eb2752b fix(artifacts): accept bare arm64e as lipo reported name for arm64e slice

📊 Changes

2 files changed (+25 additions, -3 deletions)

View changed files

📝 src/artifacts/MachOSliceArtifactReader.ts (+7 -3)
📝 tests/boundary/providers/native/artifactProvider.machOSlices.test.ts (+18 -0)

📄 Description

Summary

Fixes #4280. The lipoNameMatches guard required a variant suffix (e.g.
arm64e.v1, arm64e.x1) and rejected the bare name arm64e when lipo
reported it for an arm64e-family slice. Making the suffix optional closes
this gap without weakening the field-by-field physical-identity checks that
lipoMatchesSlice still applies.

Problem and expected behavior

On REA 6.5.0, inspect_artifact (and extract_artifact) failed with
integrity_mismatch on stock macOS universal binaries when the slice name
reported by lipo does not literally match the name the Mach-O parser
derives from the FAT table. The error message incorrectly advised the user
to rerun with integrity_policy=record-and-continue, which had no effect
on this failure path.

Smallest trigger (macOS arm64, REA 6.5.0):

rea inspect-artifact /bin/echo   # exit 1 — integrity_mismatch (false positive)

Expected: a slice whose byte ranges agree with the FAT table must not produce an integrity_mismatch. That verdict is reserved for byte-range disagreement, not naming disagreement.

Change and scope
src/artifacts/MachOSliceArtifactReader.ts: make the ABI-variant suffix optional in the regex (arm64e(\.[A-Za-z0-9_]+)?). The observed === "arm64e" guard is unchanged; physical identity (offset, size, cpu_type, cpu_subtype) is still checked field by field by lipoMatchesSlice.
tests/boundary/providers/native/artifactProvider.machOSlices.test.ts: added regression and guard test cases:
Regression: bare arm64e.x1 with ARM64E_X1 FAT CPU resolves cleanly (issue #4280).
Guard: wrong offset with ARM64E_X1 still rejects (integrity).
No new provider, execution, injection, mutation, network, or persistence effect. No API or schema change.

Contribution scope fit and linked maintainer decision: not applicable to this bounded static-analysis correction.

Contract and boundary impact
Semantic owner and earliest changed stage: artifact slice enumeration (lipoNameMatches in src/artifacts/MachOSliceArtifactReader.ts).
Contribution scope fit and linked maintainer decision: not applicable.
CLI and MCP/tool-catalog contract: no tool signature or output schema change. Slices that previously raised integrity_mismatch now enumerate correctly.
Provider, bridge, target-format, or platform compatibility: Mach-O universal (FAT) binaries on macOS arm64 with arm64e family slices.
Evidence, artifact, provenance, or reconstruction contract: unchanged. The fix removes a false integrity rejection; it does not relax byte-range or field-by-field physical checks.
Target selection, authority, upstream behavior, and cleanup details: not applicable.
Generated metadata impact: none.
Expected effects:

 Read existing files or captured data.
 Launch or attach to a process.
 Inject instrumentation or run scripts/code.
 Change process memory, registers, files, or configuration.
 Contact network services.
 Recover protected code or work around protections.
 Documentation or usability only; no target interaction.
 Not sure yet; investigation or maintainer guidance needed.
Evidence and regression coverage
Tests added or updated: 2 new cases in tests/boundary/providers/native/artifactProvider.machOSlices.test.ts (15 total, was 13).

Base reproduction: on main, the regression test fails with promise resolved instead of rejecting, and the guard test verifies wrong offsets remain rejected. After the fix, all tests pass.

User-visible CLI/MCP output: inspect_artifact on macOS arm64 no longer exits 1 with false integrity_mismatch.

Remaining proof gaps: source-derived and verified through boundary unit test fixtures; physical end-to-end macOS 27 binary testing not executed in this environment.

 Observed, derived, and inferred claims remain distinguishable.

 Artifact identity, source provenance, and failed attempts remain preserved.

 Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed
npx vitest run tests/boundary/providers/native/artifactProvider.machOSlices.test.ts --reporter=verbose — 15 passed, 0 failed
npm run check:fast — 2 tasks successful (typecheck + lint)
npm run format:check — All matched files use the correct format
Compatibility, safety, and release
Breaking changes or migration steps: none. The fix relaxes an over-strict name match guard; no valid existing behavior is modified or broken.
Real Hopper/Ghidra, browser, or OS coverage: boundary and unit test coverage.
Package or release metadata impact: none.
Security, privacy, process, or containment review: purely read-only static analysis change, no runtime or security implications.
Author readiness
Human owner: @dav9fulldev

 I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
 I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
 I declare this PR ready for initial maintainer review.
Before merge
 This PR addresses a concrete problem or an agreed enhancement.
 Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
 The PR has one focused outcome and the title follows type(scope): outcome.
 Related issue is linked, or the reason for not linking one is stated above.
 Tests cover changed observable behavior and meaningful failure paths.
 Owning docs, contracts, and generated metadata are updated where needed.
 User-visible CLI/MCP changes include representative output.
 I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

---

<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/4291 **Author:** [@dav9fulldev](https://github.com/dav9fulldev) **Created:** 10/16/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/macos-arm64e-slice-lipo` --- ### 📝 Commits (1) - [`eb2752b`](https://github.com/morluto/rea/commit/eb2752b9cf7c8cbe7f5bdce52ce5e923776bde2a) fix(artifacts): accept bare arm64e as lipo reported name for arm64e slice ### 📊 Changes **2 files changed** (+25 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `src/artifacts/MachOSliceArtifactReader.ts` (+7 -3) 📝 `tests/boundary/providers/native/artifactProvider.machOSlices.test.ts` (+18 -0) </details> ### 📄 Description ## Summary Fixes #4280. The `lipoNameMatches` guard required a variant suffix (e.g. `arm64e.v1`, `arm64e.x1`) and rejected the bare name `arm64e` when lipo reported it for an arm64e-family slice. Making the suffix optional closes this gap without weakening the field-by-field physical-identity checks that `lipoMatchesSlice` still applies. ## Problem and expected behavior On REA 6.5.0, `inspect_artifact` (and `extract_artifact`) failed with `integrity_mismatch` on stock macOS universal binaries when the slice name reported by lipo does not literally match the name the Mach-O parser derives from the FAT table. The error message incorrectly advised the user to rerun with `integrity_policy=record-and-continue`, which had no effect on this failure path. Smallest trigger (macOS arm64, REA 6.5.0): ```bash rea inspect-artifact /bin/echo # exit 1 — integrity_mismatch (false positive) Expected: a slice whose byte ranges agree with the FAT table must not produce an integrity_mismatch. That verdict is reserved for byte-range disagreement, not naming disagreement. Change and scope src/artifacts/MachOSliceArtifactReader.ts: make the ABI-variant suffix optional in the regex (arm64e(\.[A-Za-z0-9_]+)?). The observed === "arm64e" guard is unchanged; physical identity (offset, size, cpu_type, cpu_subtype) is still checked field by field by lipoMatchesSlice. tests/boundary/providers/native/artifactProvider.machOSlices.test.ts: added regression and guard test cases: Regression: bare arm64e.x1 with ARM64E_X1 FAT CPU resolves cleanly (issue #4280). Guard: wrong offset with ARM64E_X1 still rejects (integrity). No new provider, execution, injection, mutation, network, or persistence effect. No API or schema change. Contribution scope fit and linked maintainer decision: not applicable to this bounded static-analysis correction. Contract and boundary impact Semantic owner and earliest changed stage: artifact slice enumeration (lipoNameMatches in src/artifacts/MachOSliceArtifactReader.ts). Contribution scope fit and linked maintainer decision: not applicable. CLI and MCP/tool-catalog contract: no tool signature or output schema change. Slices that previously raised integrity_mismatch now enumerate correctly. Provider, bridge, target-format, or platform compatibility: Mach-O universal (FAT) binaries on macOS arm64 with arm64e family slices. Evidence, artifact, provenance, or reconstruction contract: unchanged. The fix removes a false integrity rejection; it does not relax byte-range or field-by-field physical checks. Target selection, authority, upstream behavior, and cleanup details: not applicable. Generated metadata impact: none. Expected effects: Read existing files or captured data. Launch or attach to a process. Inject instrumentation or run scripts/code. Change process memory, registers, files, or configuration. Contact network services. Recover protected code or work around protections. Documentation or usability only; no target interaction. Not sure yet; investigation or maintainer guidance needed. Evidence and regression coverage Tests added or updated: 2 new cases in tests/boundary/providers/native/artifactProvider.machOSlices.test.ts (15 total, was 13). Base reproduction: on main, the regression test fails with promise resolved instead of rejecting, and the guard test verifies wrong offsets remain rejected. After the fix, all tests pass. User-visible CLI/MCP output: inspect_artifact on macOS arm64 no longer exits 1 with false integrity_mismatch. Remaining proof gaps: source-derived and verified through boundary unit test fixtures; physical end-to-end macOS 27 binary testing not executed in this environment. Observed, derived, and inferred claims remain distinguishable. Artifact identity, source provenance, and failed attempts remain preserved. Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. Validation performed npx vitest run tests/boundary/providers/native/artifactProvider.machOSlices.test.ts --reporter=verbose — 15 passed, 0 failed npm run check:fast — 2 tasks successful (typecheck + lint) npm run format:check — All matched files use the correct format Compatibility, safety, and release Breaking changes or migration steps: none. The fix relaxes an over-strict name match guard; no valid existing behavior is modified or broken. Real Hopper/Ghidra, browser, or OS coverage: boundary and unit test coverage. Package or release metadata impact: none. Security, privacy, process, or containment review: purely read-only static analysis change, no runtime or security implications. Author readiness Human owner: @dav9fulldev I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. I declare this PR ready for initial maintainer review. Before merge This PR addresses a concrete problem or an agreed enhancement. Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. The PR has one focused outcome and the title follows type(scope): outcome. Related issue is linked, or the reason for not linking one is stated above. Tests cover changed observable behavior and meaningful failure paths. Owning docs, contracts, and generated metadata are updated where needed. User-visible CLI/MCP changes include representative output. I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:12:20 +00:00
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#6162
No description provided.