morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #1172] [MERGED] fix(artifacts): match lipo arm64e variant names to their FAT slices #2698

New issue

Closed

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

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1172
Author: @kaoru0822-kitauji
Created: 10/9/2026
Status: ✅ Merged
Merged: 10/9/2026
Merged by: @kaoru0822-kitauji

Base: main ← Head: fix/macho-arm64e-variant-slices

📝 Commits (1)

0b32577 fix(artifacts): match lipo arm64e variant names to their FAT slices

📊 Changes

2 files changed (+79 additions, -1 deletions)

View changed files

📝 src/artifacts/MachOSliceArtifactReader.ts (+10 -1)
📝 tests/boundary/providers/native/artifactProvider.machOSlices.test.ts (+69 -0)

📄 Description

Fixes #1168.

Problem

inspect_artifact reported valid, unmodified universal Mach-O files as corrupt:

{"code":"artifact_operation_failed","category":"integrity_mismatch","message":"Artifact is invalid or has changed. Get a fresh copy and try again.","details":{"operation":"inspect_artifact","reason":"integrity","detail":"lipo slice metadata disagrees with the Mach-O FAT table: arm64e.v1 (cputype=CPU_TYPE_ARM64, cpusubtype=CPU_SUBTYPE_ARM64E, offset=16384, size=33432, alignment=16384)"}}

Newer lipo names arm64e ABI variants arm64e.<variant>:

arm64e.v1 (PTR_AUTH_VERSION USERSPACE 1) for universal binaries freshly built with clang -arch arm64e and lipo -create;
arm64e.x1 for recent macOS system binaries such as /bin/ls, per the issue.

MachOSliceArtifactReader cross-checks each lipo slice against the structural FAT table, which names that slice arm64e. The exact name comparison failed, so every other field went unchecked and the file was declared inconsistent.

Change

lipoMatchesSlice accepts arm64e.<variant> (/^arm64e\.[A-Za-z0-9_]+$/) for a FAT arm64e slice. The provider's slice selection already recognizes this spelling.
Everything else is still compared field by field: offset, size, CPU type, subtype (including the pointer-auth version bits when lipo prints capabilities) and alignment. A variant name never matches a plain arm64 slice.
The slice keeps lipo's name in its logical path, for example slices/arm64e.v1.

No schemas change.

Verification

I reproduced the issue's self-built fixture on this Mac: lipo -detailed_info reports arm64e.v1. main fails with the integrity mismatch; with this change, rea inspect-artifact returns slices/arm64e.v1 and slices/x86_64.
This Mac's Command Line Tools label /bin/ls as plain arm64e, so the /bin/ls form of the issue doesn't reproduce here. Its arm64e.x1 spelling is covered by a fake-lipo test.
New artifactProvider.machOSlices.test.ts cases: arm64e.v1 with matching pointer-auth subtype bits and arm64e.x1 with an unrecognized subtype are accepted, and both fail on main. A variant name against a plain arm64 slice and a variant with a disagreeing offset are still rejected as integrity failures.
All 34 test files mentioning Mach-O or lipo: 463 passed. The one failure, src/artifacts/MachOSliceArtifactReader.test.ts, pins /bin/ls slice sizes for a particular macOS build and fails identically on unmodified main on this host.
npm run check:fast, npm run jscpd (2.49%)

No real Hopper or Ghidra verification was run, because this change does not touch those providers.

🤖 Generated with Claude Code

_{🔄 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/1172 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/9/2026 **Status:** ✅ Merged **Merged:** 10/9/2026 **Merged by:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Base:** `main` ← **Head:** `fix/macho-arm64e-variant-slices` --- ### 📝 Commits (1) - [`0b32577`](https://github.com/morluto/rea/commit/0b32577a90aef97e36adf2a7af4f3eccd5d82357) fix(artifacts): match lipo arm64e variant names to their FAT slices ### 📊 Changes **2 files changed** (+79 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/artifacts/MachOSliceArtifactReader.ts` (+10 -1) 📝 `tests/boundary/providers/native/artifactProvider.machOSlices.test.ts` (+69 -0) </details> ### 📄 Description Fixes #1168. ## Problem `inspect_artifact` reported valid, unmodified universal Mach-O files as corrupt: ```json {"code":"artifact_operation_failed","category":"integrity_mismatch","message":"Artifact is invalid or has changed. Get a fresh copy and try again.","details":{"operation":"inspect_artifact","reason":"integrity","detail":"lipo slice metadata disagrees with the Mach-O FAT table: arm64e.v1 (cputype=CPU_TYPE_ARM64, cpusubtype=CPU_SUBTYPE_ARM64E, offset=16384, size=33432, alignment=16384)"}} ``` Newer `lipo` names arm64e ABI variants `arm64e.<variant>`: - `arm64e.v1` (`PTR_AUTH_VERSION USERSPACE 1`) for universal binaries freshly built with `clang -arch arm64e` and `lipo -create`; - `arm64e.x1` for recent macOS system binaries such as `/bin/ls`, per the issue. `MachOSliceArtifactReader` cross-checks each `lipo` slice against the structural FAT table, which names that slice `arm64e`. The exact name comparison failed, so every other field went unchecked and the file was declared inconsistent. ## Change - `lipoMatchesSlice` accepts `arm64e.<variant>` (`/^arm64e\.[A-Za-z0-9_]+$/`) for a FAT `arm64e` slice. The provider's slice selection already recognizes this spelling. - Everything else is still compared field by field: offset, size, CPU type, subtype (including the pointer-auth version bits when `lipo` prints `capabilities`) and alignment. A variant name never matches a plain `arm64` slice. - The slice keeps `lipo`'s name in its logical path, for example `slices/arm64e.v1`. No schemas change. ## Verification - I reproduced the issue's self-built fixture on this Mac: `lipo -detailed_info` reports `arm64e.v1`. `main` fails with the integrity mismatch; with this change, `rea inspect-artifact` returns `slices/arm64e.v1` and `slices/x86_64`. - This Mac's Command Line Tools label `/bin/ls` as plain `arm64e`, so the `/bin/ls` form of the issue doesn't reproduce here. Its `arm64e.x1` spelling is covered by a fake-`lipo` test. - New `artifactProvider.machOSlices.test.ts` cases: `arm64e.v1` with matching pointer-auth subtype bits and `arm64e.x1` with an unrecognized subtype are accepted, and both fail on `main`. A variant name against a plain `arm64` slice and a variant with a disagreeing offset are still rejected as integrity failures. - All 34 test files mentioning Mach-O or `lipo`: 463 passed. The one failure, `src/artifacts/MachOSliceArtifactReader.test.ts`, pins `/bin/ls` slice sizes for a particular macOS build and fails identically on unmodified `main` on this host. - `npm run check:fast`, `npm run jscpd` (2.49%) No real Hopper or Ghidra verification was run, because this change does not touch those providers. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

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

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-10-31 01:05:44 +00:00

[PR #2698] [MERGED] refactor(process): give the prlimit producer budget one owner #5323

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

No description provided.

Rows
Columns