morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #8823] [Bug] Objdump evidence claims GNU identity for Apple LLVM executable #7764

New issue

Closed

opened 2026-11-03 17:35:02 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 17:35:02 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

inspect_with_objdump reports its Evidence provider as gnu.objdump / GNU objdump even when the configured executable is Apple LLVM objdump. Its limitations say the executable version and supported formats are unknown, but do not qualify the asserted GNU identity.

Reproduction

On the macOS arm64 host below, /usr/bin/objdump --version printed Apple LLVM version 21.0.0. I set REA_OBJDUMP_COMMAND=/usr/bin/objdump, then called public stdio MCP inspect_with_objdump with a self-built x86-64 Mach-O and operation: disassemble. Both compact and full profiles succeeded with exit code 0 and Evidence provider: {id: "gnu.objdump", name: "GNU objdump", version: null}; parameters.provider_executable correctly retained /usr/bin/objdump. A separate CLI rea inspect-with-objdump <fixture> disassemble --format json using the host's default objdump returned the same GNU provider label and LLVM-style Mach-O output.

Expected behavior

Preserve the caller-selected executable and observed command output without asserting an unverified implementation identity. Either admit and identify supported implementations from reliable evidence, reject unsupported ones with an actionable reason, or use a neutral identity when implementation is unknown. The exact policy is a design decision; do not infer identity solely from the executable's filename.

Impact and scope

The result can misattribute produced disassembly and implied tool semantics to GNU even though the observed executable identifies itself as Apple LLVM. The actual command and stdout remain present. This is one macOS host and one disassembly operation; other operations, host platforms, and autonomous-agent behavior are unverified.

REA version

187f3d8ccdf847d759e235c09c034e12bd83bbf2 (Kuna 1.990 validation branch)

Runtime and platform

Node 24.22.1, macOS arm64, Apple LLVM 21.0.0.

Target and artifact context

Self-built, unexecuted x86-64 Mach-O dylib; SHA-256 75423e5e9b6514152915e72b04f6b7c01742af2223ed03eea435524de12e6d88 unchanged.

Interface

MCP and CLI

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

Independent /usr/bin/objdump --version: Apple LLVM version 21.0.0. Public MCP result: provider.id: gnu.objdump, provider.name: GNU objdump, provider.version: null, parameters.provider_executable: /usr/bin/objdump, exit code 0. The MCP description says GNU objdump semantics; the implementation version limitation correctly says no reliable version probe ran.

Typed outcome or recovery expected

Unknown or independently established executable identity, with precise implementation-dependent semantics and no fabricated GNU attribution.

Analysis or suspected cause

Source-derived: src/objdump/ObjdumpProviderIdentity.ts hard-codes gnu.objdump and GNU objdump; src/composition/reverseEngineering.ts passes the caller-selected REA_OBJDUMP_COMMAND or PATH command to the provider without deriving that identity from the executable. A neutral label or version probe would need Evidence identity and backward-compatibility review.

Additional context

Related tool UX: #8360 investigates alternate instruction decoding. No claim is made that LLVM objdump is supported for every advertised operation or follows GNU semantics. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8823 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior `inspect_with_objdump` reports its Evidence provider as `gnu.objdump` / `GNU objdump` even when the configured executable is Apple LLVM objdump. Its limitations say the executable version and supported formats are unknown, but do not qualify the asserted GNU identity. ### Reproduction On the macOS arm64 host below, `/usr/bin/objdump --version` printed `Apple LLVM version 21.0.0`. I set `REA_OBJDUMP_COMMAND=/usr/bin/objdump`, then called public stdio MCP `inspect_with_objdump` with a self-built x86-64 Mach-O and `operation: disassemble`. Both compact and full profiles succeeded with exit code 0 and Evidence `provider: {id: "gnu.objdump", name: "GNU objdump", version: null}`; `parameters.provider_executable` correctly retained `/usr/bin/objdump`. A separate CLI `rea inspect-with-objdump <fixture> disassemble --format json` using the host's default `objdump` returned the same GNU provider label and LLVM-style Mach-O output. ### Expected behavior Preserve the caller-selected executable and observed command output without asserting an unverified implementation identity. Either admit and identify supported implementations from reliable evidence, reject unsupported ones with an actionable reason, or use a neutral identity when implementation is unknown. The exact policy is a design decision; do not infer identity solely from the executable's filename. ### Impact and scope The result can misattribute produced disassembly and implied tool semantics to GNU even though the observed executable identifies itself as Apple LLVM. The actual command and stdout remain present. This is one macOS host and one disassembly operation; other operations, host platforms, and autonomous-agent behavior are unverified. ### REA version `187f3d8ccdf847d759e235c09c034e12bd83bbf2` (Kuna 1.990 validation branch) ### Runtime and platform Node 24.22.1, macOS arm64, Apple LLVM 21.0.0. ### Target and artifact context Self-built, unexecuted x86-64 Mach-O dylib; SHA-256 `75423e5e9b6514152915e72b04f6b7c01742af2223ed03eea435524de12e6d88` unchanged. ### Interface MCP and CLI ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence Independent `/usr/bin/objdump --version`: `Apple LLVM version 21.0.0`. Public MCP result: `provider.id: gnu.objdump`, `provider.name: GNU objdump`, `provider.version: null`, `parameters.provider_executable: /usr/bin/objdump`, exit code 0. The MCP description says GNU objdump semantics; the implementation version limitation correctly says no reliable version probe ran. ### Typed outcome or recovery expected Unknown or independently established executable identity, with precise implementation-dependent semantics and no fabricated GNU attribution. ### Analysis or suspected cause Source-derived: `src/objdump/ObjdumpProviderIdentity.ts` hard-codes `gnu.objdump` and `GNU objdump`; `src/composition/reverseEngineering.ts` passes the caller-selected `REA_OBJDUMP_COMMAND` or PATH command to the provider without deriving that identity from the executable. A neutral label or version probe would need Evidence identity and backward-compatibility review. ### Additional context Related tool UX: #8360 investigates alternate instruction decoding. No claim is made that LLVM objdump is supported for every advertised operation or follows GNU semantics. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi closed this issue

2026-11-03 19:39:07 +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#7764

No description provided.

Rows
Columns