[GH-ISSUE #821] [Bug] Ghidra provider pins Java to exactly major 21 and the Ghidra version to the exact string "12.1.4", blocking working installs #352

New issue

Closed

opened 2026-10-15 18:24:13 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:24:13 +00:00

Owner

Originally created by @Selene0623 on GitHub (Oct 7, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/821

Summary

The Ghidra provider refuses to start unless the JDK is exactly major 21 and the Ghidra install reports exactly the string 12.1.4. Both are hard equality checks, so:

a working JDK that isn't 21 (17 or 27 here) makes the provider unusable, even though Ghidra itself runs fine under it;
a distro-packaged Ghidra can never satisfy the version test when the distro ships 12.1.2.

Environment

rea-agents 4.1.0, Linux x64 (Arch/CachyOS)
Ghidra 12.1.2-2.1 from the distro at /opt/ghidra (application.version=12.1.2)
Installed JDKs: jdk-openjdk 27.u35-2 and jdk17-openjdk 17.0.20.1. No 21.
Target: an ordinary 32-bit PE (open_binary succeeds; the provider is what fails)

What happens

rea analyze <pe> (and binary_session) fails with provider_unavailable, and the diagnostics name the two failing checks:

- provider_id: ghidra
  code: unsupported_version
  reason: "Install Ghidra 12.1.4, or update REA for a different Ghidra build."
  diagnostics:
    install_dir: /opt/ghidra
    provider_version: 12.1.2
    java_version: "17.0.20.1"
    checks[8]{name,ok,code,detail}:
      version,false,unsupported_version,12.1.2
      java,false,unsupported_version,17.0.20.1; 64-bit; JDK; /usr/lib/jvm/java-17-openjdk

Re-running with JAVA_HOME=/usr/lib/jvm/java-27-openjdk swaps the java complaint to 27 but fails identically:

      version,false,unsupported_version,12.1.2
      java,false,unsupported_version,27; 64-bit; JDK; /usr/lib/jvm/java-27-openjdk

Why both gates look over-strict

Java — SUPPORTED_GHIDRA_JAVA_MAJOR = 21 (dist/ghidra/GhidraInstallation.js:8) is compared with observation.major === SUPPORTED_GHIDRA_JAVA_MAJOR (:217). There is no range: 21 passes, 17 and 27 both fail. But Ghidra's own launcher works under 27:
```
$ JAVA_HOME=/usr/lib/jvm/java-27-openjdk /opt/ghidra/support/analyzeHeadless
openjdk version "27" 2026-09-15
OpenJDK Runtime Environment (build 27)
Headless Analyzer Usage: analyzeHeadless
           <project_location> <project_name>[/<folder_path>]
...
```
So a user on a rolling distro, where the packaged JDK is newer than 21, must install a second older JDK purely to satisfy the provider check.
Ghidra version — SUPPORTED_GHIDRA_VERSION = "12.1.4" (:6) is compared with coordinates.properties?.providerVersion === SUPPORTED_GHIDRA_VERSION (:138) — string equality, not a range. Arch/CachyOS currently ship 12.1.2, so the standard system install can never pass, and the only remediation offered is to install a different Ghidra build. Pointing GHIDRA_INSTALL_DIR at a link farm whose Ghidra/application.properties says 12.1.4 flips that single check to pass and leaves only the Java check failing, i.e. the version string is the entire gate:
```
   version,true,null,12.1.4
   headless,true,null,<farm>/support/analyzeHeadless
   java,false,unsupported_version,27; ...
```

Impact

On a rolling-release distro there is no path from the packaged Ghidra + packaged JDK to a running Ghidra provider. The workaround is to install a second JDK and a hand-managed Ghidra build, which is exactly what the provider's own diagnostics recommend but which conflicts with keeping REA's analysis honest about the versions it is running.

Suggested change

Accept JDK >= 21 (Ghidra's own documented requirement), or a supported set of majors, instead of === 21.
Accept a version range for Ghidra (e.g. >=12.1.4 <12.2) instead of exact string equality, or provide an explicit override plus a doctor warning that the build is untested.
Have the failure message state which versions are accepted, so the diagnostics are actionable without reading the source.

Happy to test a patch against Ghidra 12.1.2 + JDK 17/27 if you want a co-operative reporter.

Originally created by @Selene0623 on GitHub (Oct 7, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/821 ## Summary The Ghidra provider refuses to start unless the JDK is **exactly major 21** *and* the Ghidra install reports **exactly the string `12.1.4`**. Both are hard equality checks, so: - a working JDK that isn't 21 (17 or 27 here) makes the provider unusable, even though Ghidra itself runs fine under it; - a distro-packaged Ghidra can never satisfy the version test when the distro ships 12.1.2. ## Environment - `rea-agents` 4.1.0, Linux x64 (Arch/CachyOS) - Ghidra `12.1.2-2.1` from the distro at `/opt/ghidra` (`application.version=12.1.2`) - Installed JDKs: `jdk-openjdk 27.u35-2` and `jdk17-openjdk 17.0.20.1`. No 21. - Target: an ordinary 32-bit PE (`open_binary` succeeds; the provider is what fails) ## What happens `rea analyze <pe>` (and `binary_session`) fails with `provider_unavailable`, and the diagnostics name the two failing checks: ``` - provider_id: ghidra code: unsupported_version reason: "Install Ghidra 12.1.4, or update REA for a different Ghidra build." diagnostics: install_dir: /opt/ghidra provider_version: 12.1.2 java_version: "17.0.20.1" checks[8]{name,ok,code,detail}: version,false,unsupported_version,12.1.2 java,false,unsupported_version,17.0.20.1; 64-bit; JDK; /usr/lib/jvm/java-17-openjdk ``` Re-running with `JAVA_HOME=/usr/lib/jvm/java-27-openjdk` swaps the java complaint to `27` but fails identically: ``` version,false,unsupported_version,12.1.2 java,false,unsupported_version,27; 64-bit; JDK; /usr/lib/jvm/java-27-openjdk ``` ## Why both gates look over-strict 1. **Java** — `SUPPORTED_GHIDRA_JAVA_MAJOR = 21` (`dist/ghidra/GhidraInstallation.js:8`) is compared with `observation.major === SUPPORTED_GHIDRA_JAVA_MAJOR` (`:217`). There is no range: 21 passes, 17 and 27 both fail. But Ghidra's own launcher works under 27: ``` $ JAVA_HOME=/usr/lib/jvm/java-27-openjdk /opt/ghidra/support/analyzeHeadless openjdk version "27" 2026-09-15 OpenJDK Runtime Environment (build 27) Headless Analyzer Usage: analyzeHeadless <project_location> <project_name>[/<folder_path>] ... ``` So a user on a rolling distro, where the packaged JDK is newer than 21, must install a second older JDK purely to satisfy the provider check. 2. **Ghidra version** — `SUPPORTED_GHIDRA_VERSION = "12.1.4"` (`:6`) is compared with `coordinates.properties?.providerVersion === SUPPORTED_GHIDRA_VERSION` (`:138`) — string equality, not a range. Arch/CachyOS currently ship 12.1.2, so the standard system install can never pass, and the only remediation offered is to install a different Ghidra build. Pointing `GHIDRA_INSTALL_DIR` at a link farm whose `Ghidra/application.properties` says `12.1.4` flips that single check to pass and leaves only the Java check failing, i.e. the version string is the entire gate: ``` version,true,null,12.1.4 headless,true,null,<farm>/support/analyzeHeadless java,false,unsupported_version,27; ... ``` ## Impact On a rolling-release distro there is no path from the packaged Ghidra + packaged JDK to a running Ghidra provider. The workaround is to install a second JDK and a hand-managed Ghidra build, which is exactly what the provider's own diagnostics recommend but which conflicts with keeping REA's analysis honest about the versions it is running. ## Suggested change - Accept **JDK >= 21** (Ghidra's own documented requirement), or a supported set of majors, instead of `=== 21`. - Accept a **version range** for Ghidra (e.g. `>=12.1.4 <12.2`) instead of exact string equality, or provide an explicit override plus a `doctor` warning that the build is untested. - Have the failure message state which versions *are* accepted, so the diagnostics are actionable without reading the source. Happy to test a patch against Ghidra 12.1.2 + JDK 17/27 if you want a co-operative reporter.

bsakaguchi

2026-10-15 18:24:13 +00:00