[GH-ISSUE #5381] [Bug] PATH-discovered Ghidra registration pins a versioned Cellar root #3259

New issue

Closed

opened 2026-10-31 00:38:30 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:38:30 +00:00

Owner

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

Before submitting

Searched open and closed issues and PRs for GHIDRA_INSTALL_DIR, Cellar, stable paths and upgrades.
Only authored temporary paths and synthetic installation data are involved.

Area

Setup, packaging, or upgrade.

Observed behavior

A controlled production-boundary probe of PATH discovery, installation inspection and doctor projection publishes a version-specific GHIDRA_INSTALL_DIR, even when the PATH launcher traverses a stable opt symlink. After switching that symlink and removing the old version, the published directory is missing while the stable path and fresh discovery still work.

This is an executed filesystem/adapter probe, not a full setup or real Homebrew/Ghidra reproduction. The Java observation is controlled; no Java or Ghidra executable was run.

Reproduction

Executed once after correcting the fixture's /var versus /private/var alias assertion:

Create authored complete-looking trees <prefix>/Cellar/ghidra/{12.1.4,12.1.5}/libexec, containing application properties, executable launcher/headless/decompiler placeholders.
Create opt/ghidra -> ../Cellar/ghidra/12.1.4 and bin/ghidra -> ../opt/ghidra/libexec/ghidraRun.
Call discoverGhidraInstallationOnPath({ PATH: '<prefix>/bin' }, 'darwin'), then inspectGhidraInstallation with that same real discovery and filesystem observations, a controlled supported Java result, and no executable-header seam. Project with projectGhidraDoctorInspection.
Switch opt/ghidra to 12.1.5 and remove 12.1.4. Check the projected registration path and stable path, then repeat discovery.

Relevant output or evidence

Reduced actual output, with the random temporary prefix replaced:

{
  "discovered": "<prefix>/Cellar/ghidra/12.1.4/libexec",
  "registered": "<prefix>/Cellar/ghidra/12.1.4/libexec",
  "afterUpgrade": {
    "registeredExists": false,
    "stableOptRootExists": true,
    "freshDiscovery": "<prefix>/Cellar/ghidra/12.1.5/libexec"
  }
}

The producing PATH discovery realpaths the launcher and returns its directory. Doctor projection uses that directory directly as registrationEnvironment.GHIDRA_INSTALL_DIR. Setup's use of that environment is source-derived; this probe did not write a client configuration.

Expected behavior

When an existing stable opt directory can be proven to resolve to the same validated discovered root, publish that stable spelling for registration. Preserve an explicitly selected GHIDRA_INSTALL_DIR, and retain the discovered root when alias identity cannot be proven. Homebrew documents its opt prefix as the active-keg symlink.

Impact and scope

A registration created from PATH discovery can become stale after package-manager cleanup. Actual Homebrew upgrade behavior, affected installations and frequency are NOT_ENOUGH_INFO: only the authored layout was exercised. No target analysis, arbitrary process execution, identity bypass or unrelated installation is involved.

REA version

Source 799e8265b254e225dc1dabdd25e56f0ab7f86bd3, package 6.7.0, with unrelated local changes. The Ghidra discovery/doctor files are unchanged from that revision.

Runtime and platform

Node 24.18.0, Darwin 25.3.0 arm64. Java/Ghidra versions are controlled fixture observations, not installed-provider verification.

Target and artifact context

Authored filesystem directories and symlinks; no analysis target.

Interface / earliest failure stage

Shared setup/doctor boundary; setup or provider admission.

This follows #5264, but affects Ghidra's discovered root rather than the JVM-reported JAVA_HOME. PR #5308 only changes Java home spelling and does not change this discovery. #4847/PR #4994 concern the REA launcher entrypoint. A directory-identity-checked alias at the discovery owner would address this case without downstream configuration rewrites. No fix is claimed in this report.

Originally created by @morluto on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5381 ## Before submitting - [x] Searched open and closed issues and PRs for GHIDRA_INSTALL_DIR, Cellar, stable paths and upgrades. - [x] Only authored temporary paths and synthetic installation data are involved. ## Area Setup, packaging, or upgrade. ## Observed behavior A controlled production-boundary probe of PATH discovery, installation inspection and doctor projection publishes a version-specific `GHIDRA_INSTALL_DIR`, even when the PATH launcher traverses a stable `opt` symlink. After switching that symlink and removing the old version, the published directory is missing while the stable path and fresh discovery still work. This is an executed filesystem/adapter probe, not a full setup or real Homebrew/Ghidra reproduction. The Java observation is controlled; no Java or Ghidra executable was run. ## Reproduction Executed once after correcting the fixture's `/var` versus `/private/var` alias assertion: 1. Create authored complete-looking trees `<prefix>/Cellar/ghidra/{12.1.4,12.1.5}/libexec`, containing application properties, executable launcher/headless/decompiler placeholders. 2. Create `opt/ghidra -> ../Cellar/ghidra/12.1.4` and `bin/ghidra -> ../opt/ghidra/libexec/ghidraRun`. 3. Call `discoverGhidraInstallationOnPath({ PATH: '<prefix>/bin' }, 'darwin')`, then `inspectGhidraInstallation` with that same real discovery and filesystem observations, a controlled supported Java result, and no executable-header seam. Project with `projectGhidraDoctorInspection`. 4. Switch `opt/ghidra` to 12.1.5 and remove 12.1.4. Check the projected registration path and stable path, then repeat discovery. ## Relevant output or evidence Reduced actual output, with the random temporary prefix replaced: ```json { "discovered": "<prefix>/Cellar/ghidra/12.1.4/libexec", "registered": "<prefix>/Cellar/ghidra/12.1.4/libexec", "afterUpgrade": { "registeredExists": false, "stableOptRootExists": true, "freshDiscovery": "<prefix>/Cellar/ghidra/12.1.5/libexec" } } ``` The producing [PATH discovery](https://github.com/morluto/rea/blob/799e8265b254e225dc1dabdd25e56f0ab7f86bd3/src/ghidra/GhidraInstallation.ts#L1003-L1047) realpaths the launcher and returns its directory. [Doctor projection](https://github.com/morluto/rea/blob/799e8265b254e225dc1dabdd25e56f0ab7f86bd3/src/ghidra/GhidraDoctor.ts#L29-L37) uses that directory directly as registrationEnvironment.GHIDRA_INSTALL_DIR. Setup's use of that environment is source-derived; this probe did not write a client configuration. ## Expected behavior When an existing stable `opt` directory can be proven to resolve to the same validated discovered root, publish that stable spelling for registration. Preserve an explicitly selected `GHIDRA_INSTALL_DIR`, and retain the discovered root when alias identity cannot be proven. Homebrew documents its [opt prefix as the active-keg symlink](https://docs.brew.sh/Formula-Cookbook#formula-cookbook). ## Impact and scope A registration created from PATH discovery can become stale after package-manager cleanup. Actual Homebrew upgrade behavior, affected installations and frequency are NOT_ENOUGH_INFO: only the authored layout was exercised. No target analysis, arbitrary process execution, identity bypass or unrelated installation is involved. ## REA version Source `799e8265b254e225dc1dabdd25e56f0ab7f86bd3`, package 6.7.0, with unrelated local changes. The Ghidra discovery/doctor files are unchanged from that revision. ## Runtime and platform Node 24.18.0, Darwin 25.3.0 arm64. Java/Ghidra versions are controlled fixture observations, not installed-provider verification. ## Target and artifact context Authored filesystem directories and symlinks; no analysis target. ## Interface / earliest failure stage Shared setup/doctor boundary; setup or provider admission. ## Analysis and related work This follows #5264, but affects Ghidra's discovered root rather than the JVM-reported JAVA_HOME. PR #5308 only changes Java home spelling and does not change this discovery. #4847/PR #4994 concern the REA launcher entrypoint. A directory-identity-checked alias at the discovery owner would address this case without downstream configuration rewrites. No fix is claimed in this report.

bsakaguchi closed this issue

2026-10-31 00:38:30 +00:00

bsakaguchi referenced this issue

2026-10-31 01:08:34 +00:00

[PR #3259] [CLOSED] fix(rea): explain display-only bundle differences inline #5680