morluto/rea

Fork 0

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

[GH-ISSUE #7459] [Docs] jadx-headless-mcp dependency name collides with an unrelated public npm/GitHub project #4453

New issue

Open

opened 2026-10-31 00:49:56 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:49:56 +00:00

Owner

Originally created by @dadgoodlyfam-blip on GitHub (Oct 27, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7459

Before submitting

I searched the existing issues for a related documentation report.
I removed credentials, tokens, private paths, and sensitive target data.

Documentation location

third_party/README.md (jadx-headless-mcp entry) and skills/reverse-engineer-anything/references/android-applications.md

Problem

The docs correctly pin the genuine upstream (github.com/1013503897/jadx-headless-mcp v0.7.1, sha256 6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75, matches dist/android/JadxRelease.js). However, there is an unrelated, independently-maintained public npm package also named "jadx-headless-mcp" (by maintainer "sameelsummer", repo github.com/Samael-Z/jadx-headless-mcp) and unrelated GitHub repos with similar names. An agent or user following the docs' instruction to "supply a separately obtained JAR" could reasonably search npm for the exact dependency name REA documents and install the wrong, unrelated, unaudited package instead - which in the npm case fetches a platform binary from its own GitHub releases at runtime with no hash verification shown in the install flow. This is a real risk surface: the docs name the dependency without flagging that an identically-named but unrelated package exists on npm.

Expected content

Suggest adding one sentence next to the REA_JADX_MCP_JAR / third_party instructions: explicitly state that the JAR must be obtained from the pinned source (github.com/1013503897/jadx-headless-mcp, release v0.7.1) and its SHA-256 verified against the value in JadxRelease.js (6e5eacf5...), since the exact same package name exists elsewhere (e.g. on npm) as an unrelated, unaudited project that executes an unverified downloaded binary. A short "do not trust a same-named package without checking the hash" warning would close this gap.

Supporting evidence

Pinned/genuine source (confirmed, hash matches): github.com/1013503897/jadx-headless-mcp, release v0.7.1, commit 5844800a486d2248fa949b74c9896285f5b54de2
Colliding npm package (unrelated, unverified binary fetch at runtime, no hash check in its install path): npmjs.com/package/jadx-headless-mcp, maintainer "sameelsummer", repo github.com/Samael-Z/jadx-headless-mcp
Verified independently by downloading the pinned URL from JadxRelease.js and computing its SHA-256 locally; it matched 6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75 exactly.

Additional context

No response

Originally created by @dadgoodlyfam-blip on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7459 ### Before submitting - [x] I searched the existing issues for a related documentation report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location third_party/README.md (jadx-headless-mcp entry) and skills/reverse-engineer-anything/references/android-applications.md ### Problem The docs correctly pin the genuine upstream (github.com/1013503897/jadx-headless-mcp v0.7.1, sha256 6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75, matches dist/android/JadxRelease.js). However, there is an unrelated, independently-maintained public npm package also named "jadx-headless-mcp" (by maintainer "sameelsummer", repo github.com/Samael-Z/jadx-headless-mcp) and unrelated GitHub repos with similar names. An agent or user following the docs' instruction to "supply a separately obtained JAR" could reasonably search npm for the exact dependency name REA documents and install the wrong, unrelated, unaudited package instead - which in the npm case fetches a platform binary from its own GitHub releases at runtime with no hash verification shown in the install flow. This is a real risk surface: the docs name the dependency without flagging that an identically-named but unrelated package exists on npm. ### Expected content Suggest adding one sentence next to the REA_JADX_MCP_JAR / third_party instructions: explicitly state that the JAR must be obtained from the pinned source (github.com/1013503897/jadx-headless-mcp, release v0.7.1) and its SHA-256 verified against the value in JadxRelease.js (6e5eacf5...), since the exact same package name exists elsewhere (e.g. on npm) as an unrelated, unaudited project that executes an unverified downloaded binary. A short "do not trust a same-named package without checking the hash" warning would close this gap. ### Supporting evidence - Pinned/genuine source (confirmed, hash matches): github.com/1013503897/jadx-headless-mcp, release v0.7.1, commit 5844800a486d2248fa949b74c9896285f5b54de2 - Colliding npm package (unrelated, unverified binary fetch at runtime, no hash check in its install path): npmjs.com/package/jadx-headless-mcp, maintainer "sameelsummer", repo github.com/Samael-Z/jadx-headless-mcp - Verified independently by downloading the pinned URL from JadxRelease.js and computing its SHA-256 locally; it matched 6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75 exactly. ### Additional context _No response_

bsakaguchi added the

documentation

triage

labels

2026-10-31 00:49:56 +00:00

bsakaguchi commented

2026-10-31 00:49:57 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 27, 2026):

Agreed, this is a real supply-chain risk surface worth fixing. The suggested one-sentence warning is good, and I'd add that the docs should reference the dependency by its full pinned source (repo + tag + sha256) rather than the bare name, so readers never land on the npm search page. For the npm case specifically, calling out that the unrelated package executes a runtime-downloaded platform binary with no hash verification is exactly the kind of detail that makes the warning actionable.

@XinwangTao commented on GitHub (Oct 27, 2026): Agreed, this is a real supply-chain risk surface worth fixing. The suggested one-sentence warning is good, and I'd add that the docs should reference the dependency by its full pinned source (repo + tag + sha256) rather than the bare name, so readers never land on the npm search page. For the npm case specifically, calling out that the unrelated package executes a runtime-downloaded platform binary with no hash verification is exactly the kind of detail that makes the warning actionable.

bsakaguchi referenced this issue

2026-10-31 01:13:03 +00:00

[PR #4453] [CLOSED] fix(analysis): require an exact modelContext receiver segment for WebMCP declarations #6251

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

No description provided.

Rows
Columns