[PR #2837] [CLOSED] fix(targets): recognize WebAssembly before inferring a .hop database #5428

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

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2837
Author: @yasshmittal
Created: 10/13/2026
Status: ❌ Closed

Base: main ← Head: fix/targets-wasm-before-hop-database


📝 Commits (1)

  • 5e502d0 fix(targets): recognize WebAssembly before inferring a .hop database

📊 Changes

2 files changed (+60 additions, -10 deletions)

View changed files

📝 src/application/BinaryTargetResolver.ts (+34 -10)
📝 tests/boundary/filesystem/binaryTarget.test.ts (+26 -0)

📄 Description

Summary

Fixes #2606.

Automatic target admission treated any path ending in .hop as an analysis database before reading its header. A WebAssembly v1 module named module.hop therefore received a database identity, while the same bytes named module.wasm received the documented wasm_requires_static_inspection constraint and its recovery guidance. A filename alone changed the recognized module's identity.

Problem and expected behavior

In parseBinaryTarget (src/application/BinaryTargetResolver.ts), the extension-based database inference returned before detectArtifactFormat checked the WebAssembly header. Recognized content should take precedence over an extension guess.

Change and scope

  • The .hop inference now goes through inferredDatabase, which first rules out a recognized WebAssembly v1 header.
  • The header check is shared with detectArtifactFormat (isWebAssemblyV1 / webAssemblyTargetError), so WebAssembly recognition still has one owner.
  • An explicitly selected targetKind: "database" is preserved, because it is a caller choice rather than an inference.
  • The containing function's complexity is unchanged.

Not included: refusing other recognized formats (for example Mach-O or ZIP) named .hop. The repository does not model a Hopper database signature, so a broader content-over-extension rule could reject real databases; the issue and its evidence concern WebAssembly.

Contribution scope: an ordinary fix within existing boundaries; no maintainer scope decision applies.

Contract and boundary impact

  • Semantic owner and earliest changed stage: target admission in src/application/BinaryTargetResolver.ts.

  • Contribution scope fit and linked maintainer decision: not applicable (bug fix).

  • CLI and MCP/tool-catalog contract: a WebAssembly module named .hop now returns the existing wasm_requires_static_inspection failure instead of a database target.

  • Provider, bridge, target-format, or platform compatibility: real .hop databases (no WebAssembly header) are unchanged.

  • Evidence, artifact, provenance, or reconstruction contract: unchanged.

  • Target selection, authority, upstream behavior, and cleanup details: explicit database target kind is preserved.

  • Generated metadata, package, or installation impact: none.

  • Read existing files or captured data.

Evidence and regression coverage

  • Tests added or updated: tests/boundary/filesystem/binaryTarget.test.ts.

    • module.wasm and module.hop with the same 8-byte WebAssembly v1 header both return wasm_requires_static_inspection.
    • With targetKind: "database", the .hop path still opens as a database.
  • Base reproduction or other evidence: on the base revision the .hop case resolves as kind: "database", and the new test fails.

  • User-visible CLI/MCP output: the existing WebAssembly constraint and its static-inspection remediation.

  • Remaining proof gaps: none known for this path.

  • 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

Host: Windows 11, Node.js 24.21.0.

  • npx vitest run --project boundary tests/boundary/filesystem/binaryTarget.test.ts tests/boundary/filesystem/targetDiagnostics.test.ts: 62 passed, 9 skipped (platform-gated). The new test fails on the base revision.
  • AnalysisProviderRegistry, config and directAnalysisPermissions suites: pass. Two HopperProviderDiscovery launcher tests fail identically on the unmodified base revision on Windows.
  • npm run check, npm run verify:test-discovery: passed; no new lint warnings.

Compatibility, safety, and release

  • Breaking changes or migration steps: none.
  • Real Hopper/Ghidra, browser, or OS coverage: Windows only; no real Hopper run.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: one additional 8-byte header read for .hop paths; no new process or network behavior.

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.

🤖 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/2837 **Author:** [@yasshmittal](https://github.com/yasshmittal) **Created:** 10/13/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/targets-wasm-before-hop-database` --- ### 📝 Commits (1) - [`5e502d0`](https://github.com/morluto/rea/commit/5e502d020fd56a6965658ac29db026d7f62fe0f2) fix(targets): recognize WebAssembly before inferring a .hop database ### 📊 Changes **2 files changed** (+60 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `src/application/BinaryTargetResolver.ts` (+34 -10) 📝 `tests/boundary/filesystem/binaryTarget.test.ts` (+26 -0) </details> ### 📄 Description ## Summary Fixes #2606. Automatic target admission treated any path ending in `.hop` as an analysis database before reading its header. A WebAssembly v1 module named `module.hop` therefore received a database identity, while the same bytes named `module.wasm` received the documented `wasm_requires_static_inspection` constraint and its recovery guidance. A filename alone changed the recognized module's identity. ## Problem and expected behavior In `parseBinaryTarget` (`src/application/BinaryTargetResolver.ts`), the extension-based database inference returned before `detectArtifactFormat` checked the WebAssembly header. Recognized content should take precedence over an extension guess. ## Change and scope - The `.hop` inference now goes through `inferredDatabase`, which first rules out a recognized WebAssembly v1 header. - The header check is shared with `detectArtifactFormat` (`isWebAssemblyV1` / `webAssemblyTargetError`), so WebAssembly recognition still has one owner. - An explicitly selected `targetKind: "database"` is preserved, because it is a caller choice rather than an inference. - The containing function's complexity is unchanged. Not included: refusing other recognized formats (for example Mach-O or ZIP) named `.hop`. The repository does not model a Hopper database signature, so a broader content-over-extension rule could reject real databases; the issue and its evidence concern WebAssembly. Contribution scope: an ordinary fix within existing boundaries; no maintainer scope decision applies. ## Contract and boundary impact - Semantic owner and earliest changed stage: target admission in `src/application/BinaryTargetResolver.ts`. - Contribution scope fit and linked maintainer decision: not applicable (bug fix). - CLI and MCP/tool-catalog contract: a WebAssembly module named `.hop` now returns the existing `wasm_requires_static_inspection` failure instead of a database target. - Provider, bridge, target-format, or platform compatibility: real `.hop` databases (no WebAssembly header) are unchanged. - Evidence, artifact, provenance, or reconstruction contract: unchanged. - Target selection, authority, upstream behavior, and cleanup details: explicit `database` target kind is preserved. - Generated metadata, package, or installation impact: none. - [x] Read existing files or captured data. ## Evidence and regression coverage - Tests added or updated: `tests/boundary/filesystem/binaryTarget.test.ts`. - `module.wasm` and `module.hop` with the same 8-byte WebAssembly v1 header both return `wasm_requires_static_inspection`. - With `targetKind: "database"`, the `.hop` path still opens as a database. - Base reproduction or other evidence: on the base revision the `.hop` case resolves as `kind: "database"`, and the new test fails. - User-visible CLI/MCP output: the existing WebAssembly constraint and its static-inspection remediation. - Remaining proof gaps: none known for this path. - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed Host: Windows 11, Node.js 24.21.0. - `npx vitest run --project boundary tests/boundary/filesystem/binaryTarget.test.ts tests/boundary/filesystem/targetDiagnostics.test.ts`: 62 passed, 9 skipped (platform-gated). The new test fails on the base revision. - `AnalysisProviderRegistry`, `config` and `directAnalysisPermissions` suites: pass. Two `HopperProviderDiscovery` launcher tests fail identically on the unmodified base revision on Windows. - `npm run check`, `npm run verify:test-discovery`: passed; no new lint warnings. ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: Windows only; no real Hopper run. - Package or release metadata impact: none. - Security, privacy, process, or containment review: one additional 8-byte header read for `.hop` paths; no new process or network behavior. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. 🤖 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-31 01:06:33 +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#5428
No description provided.