morluto/rea

Fork 0

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

[PR #3422] [MERGED] fix(hopper): keep automated Linux setup off non-x86_64 hosts #5734

New issue

Closed

opened 2026-10-31 01:09:01 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:09:01 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/3422
Author: @DavidFB-creator
Created: 10/14/2026
Status: ✅ Merged
Merged: 10/22/2026
Merged by: @morluto

Base: main ← Head: fix/3419-hopper-linux-architecture

📝 Commits (4)

dca573d fix(hopper): keep automated Linux setup off non-x86_64 hosts
ad47dcc fix(hopper): install Linux Hopper from the setup host's distribution facts
a8290eb fix(verify-package): require Hopper readiness only where Linux setup installs it
abb451f Merge remote-tracking branch 'origin/main' into sweep/3422

📊 Changes

12 files changed (+180 additions, -53 deletions)

View changed files

📝 docs/installation.md (+4 -2)
📝 scripts/verify-package-discovery.d.mts (+2 -1)
📝 scripts/verify-package-discovery.mjs (+12 -13)
📝 src/application/Doctor.test.ts (+1 -1)
📝 src/application/Doctor.ts (+1 -1)
📝 src/application/DoctorDiagnostics.ts (+2 -2)
📝 src/application/LinuxHopper.test.ts (+30 -12)
📝 src/application/LinuxHopper.ts (+40 -12)
📝 src/application/Setup.recovery.test.ts (+1 -1)
📝 src/application/SetupHost.ts (+9 -5)
📝 src/setupEnvironment.test.ts (+49 -0)
📝 tests/evaluation/package/packageSetupSupport.test.ts (+29 -3)

📄 Description

Summary

Fixes #3419. On Linux arm64 hosts, rea setup treated automated Hopper installation as supported whenever /etc/os-release matched a tested distribution. Every pinned Linux Hopper package is x86_64-only, so on such hosts setup planned and asked for approval of an install that cannot succeed. This change refuses that install up front instead.

Problem and expected behavior

Smallest trigger, on Ubuntu 24.04 aarch64: rea setup --client codex --install-hopper --json returned needs_confirmation with an install_hopper action for Hopper-6.4.2-Linux-demo.deb. With --yes, it would go on to download that package and run pkexec apt-get install.

Violated invariant: hopperSetupSupported should only be true where the pinned package can be installed. The pinned packages declare Architecture: amd64 (deb), x86_64 (RPM lead) and arch = x86_64 (Arch .PKGINFO).

Expected behavior: on non-x86_64 Linux, setup should report needs_human with a remediation before any download or package-manager call. This is the same path unsupported distributions such as Debian already take, so that recovery path is unchanged.

Change and scope

Owning boundary: parseLinuxDistribution / readLinuxDistribution now take the host architecture. hopperSetupSupported additionally requires it to match SUPPORTED_RELEASE_ARCHITECTURE (x64). The comment on that constant records how the package metadata was read.
Consumers: setup planning, setup preflight, installLinuxHopper and verify-package-discovery.mjs already read hopperSetupSupported. They now inherit the corrected decision with no downstream repair.
Wiring: the doctor host passes its injected architecture. The setup host takes its Linux distribution from the doctor host, as it already does for macosVersion, so planning and doctor share one host-fact owner. The Linux install host takes the same distribution reader from the setup host (ad47dcce3, from review), so planning, preflight and installation cannot disagree. The unused default install host on installLinuxHopper, which read process.env and process.arch directly, is removed.
Remediation text: the duplicated list of supported hosts in setup and doctor remediation moves to LINUX_HOPPER_SETUP_HOSTS and now names x86_64. docs/installation.md#hopper is updated to match.
Package verification (a8290eb00, from review): on Linux, packageSetupSupport now requires doctor Hopper readiness only where the automated installer applies (hopperSetupSupported === true); macOS is unchanged. This narrows the readiness assertion from #2973: on hosts outside the installer matrix, such as Kali and ubuntu-24.04-arm, package verification no longer asserts that the doctor admits the configured HOPPER_LAUNCHER_PATH launcher.
Unchanged: macOS Hopper setup, REA host support (supportsReaHost still accepts arm64 Linux), Ghidra/IDA, and the pinned releases themselves.

Contribution scope: a routine fix within existing setup boundaries, so no maintainer scope decision applies.

Contract and boundary impact

Semantic owner and earliest changed stage: LinuxHopper.parseLinuxDistribution, setup/provider admission.
Contribution scope fit and linked maintainer decision: not applicable (routine fix within existing boundaries).
CLI and MCP/tool-catalog contract: no schema change. On non-x86_64 Linux, setup --install-hopper now returns needs_human with the new remediation instead of needs_confirmation. The setup and doctor remediation strings change wording on all hosts.
Provider, bridge, target-format, or platform compatibility: automated Hopper setup is no longer offered on Linux arm64 or other non-x64 architectures. An existing Hopper launcher via HOPPER_LAUNCHER_PATH is unaffected.
Evidence, artifact, provenance, or reconstruction contract: none.
Target selection, authority, upstream behavior, and cleanup details: removes a planned network download and privileged package-manager call on hosts where they cannot succeed.
Generated metadata, package, or installation impact: on ubuntu-24.04-arm, package verification now expects needs_human for the explicit --install-hopper run, because both sides read the same readLinuxDistribution(process.arch) decision. On Linux hosts outside the installer matrix (Kali, ubuntu-24.04-arm), package verification no longer requires doctor Hopper readiness.

Expected effects:

Read existing files or captured data. (/etc/os-release, unchanged)
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Tests added or updated:
- LinuxHopper.test.ts: every tested distribution on arm64 keeps its package family and REA host support but has hopperSetupSupported: false. The x64 cases are unchanged.
- packageSetupSupport.test.ts: the packaged verifier does not expect automated Hopper on arm64 Ubuntu 24.04, and on Linux it no longer requires Hopper readiness where the installer does not apply (arm64 Ubuntu 24.04, Kali). Both cases fail without the a8290eb00 change.
- setupEnvironment.test.ts: the real systemSetupHost installs Linux Hopper from the selected doctor host's classification. A supported x64 fixture reaches the (mocked, refused) download; an unsupported arm64 fixture returns unsupported_host without any download.
- The setup and doctor remediation expectations are updated.
Base reproduction (executed): with the new architecture condition replaced by true (base behavior), all 7 new cases fail. They pass with it restored. With the install host reading readLinuxDistribution(process.arch) directly again, the new setupEnvironment.test.ts x64 case fails on this arm64 host; on an x64 host the arm64 case would fail instead (source-derived, not run).

User-visible CLI output (executed on Ubuntu 24.04.5 LTS aarch64, Node 24.18.1, isolated HOME):

# before: npx rea-agents@6.4.0 setup --client codex --install-hopper --json
{"status":"needs_confirmation","remediation":"Review the setup plan, then rerun interactively or with --yes.","planned":["install_hopper","configure_client","install_skill"],"applied":[]}

# after: node scripts/rea.mjs setup --client codex --install-hopper --json
{"status":"needs_human","remediation":"Automated Hopper setup requires an x86_64 host running Ubuntu 24.04+, Fedora 41+, Nobara 44+, Arch Linux, CachyOS, or Omarchy; configure an existing supported provider instead.","planned":["install_hopper","configure_client","install_skill"],"applied":[]}

# after, with --yes
{"status":"needs_human","remediation":"Automated Hopper setup requires an x86_64 host running …","applied":[]}

In the --yes run, no file was written under the isolated HOME, no rea-hopper-* temporary directory was created, and dpkg -s hopper reports the package as not installed. I did not run the base build with --yes, because it would attempt the real package install.

Remaining proof gaps:
- Not run on an x86_64 Linux host. That path is covered only by the unchanged x64 unit cases.
- Interactive (TTY) setup on arm64 not exercised; source-derived, it uses the same hopperInstallSupported gate.
- The CI ubuntu-24.04-arm package lane has not run yet; the same npm run verify:package passes locally on aarch64.

Validation performed

npm run test:local -- src/application/LinuxHopper.test.ts src/application/Setup.recovery.test.ts src/application/Doctor.test.ts src/application/Setup.planning.test.ts src/application/Setup.configuration.test.ts src/ghidra/GhidraDoctor.test.ts tests/evaluation/package/packageSetupSupport.test.ts — 7 files, 156 tests passed
Same two new-test files with the architecture condition replaced by true — 7 failed (expected), then restored
npm run test:local -- src/setupEnvironment.test.ts src/application/LinuxHopper.test.ts — 2 files, 59 tests passed
Same setupEnvironment.test.ts with the install host reading the ambient host again — 1 failed (expected, x64 case on arm64), then restored
npm run test:local -- tests/evaluation/package/packageSetupSupport.test.ts — 6 passed; without the a8290eb00 change, 2 failed (expected)
npm run test:changed -- --base origin/main — 30 files, 534 tests passed (on ad47dcce3 and again on a8290eb00)
npm run check:fast — typecheck and lint passed
npm run format:check — passed
npm run docs:check — passed
npm run build:cached plus the CLI runs above on Ubuntu 24.04.5 aarch64 — results as shown
npm run verify:package on Ubuntu 24.04.5 aarch64, Node 24.18.1 — exit 0 on dca573dd4, ad47dcce3 and a8290eb00; all 18 stages complete, including package discovery and setup and uninstall CLI

Compatibility, safety, and release

Breaking changes or migration steps: none. On non-x64 Linux, explicit --install-hopper now stops with needs_human instead of attempting an install that could not succeed. Remediation wording changes.
Real Hopper/Ghidra, browser, or OS coverage: real setup CLI on Ubuntu 24.04 aarch64, without Hopper because no arm64 package exists. Not run on x86_64 Linux or macOS.
Package or release metadata impact: none beyond the CI expectations noted above.
Security, privacy, process, or containment review: reduces privileged package-manager invocations and external downloads on unsupported hosts. No new effects.

Author readiness

Human owner: @DavidFB-creator

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

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.

Maintainer blocker verification

macOS arm64, Node 24.18.0/npm 11.16.0, exact head abb451f4cb23bd10dd83381e296fb58fad6e20a2: npm pack --dry-run --json passed through prepack (1,671 files, including Linux Hopper/setup outputs). npm run verify:package passed archive, install/update, CLI/MCP, setup/uninstall and cleanup checks, including read-only setup planning and preservation of existing Hopper. This run did not verify additional OS hosts.

_{🔄 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/3422 **Author:** [@DavidFB-creator](https://github.com/DavidFB-creator) **Created:** 10/14/2026 **Status:** ✅ Merged **Merged:** 10/22/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/3419-hopper-linux-architecture` --- ### 📝 Commits (4) - [`dca573d`](https://github.com/morluto/rea/commit/dca573dd4e4775d0055f9a2063ac325c90dfafbc) fix(hopper): keep automated Linux setup off non-x86_64 hosts - [`ad47dcc`](https://github.com/morluto/rea/commit/ad47dcce30d387bb448e18752fc4dd62e422ef7b) fix(hopper): install Linux Hopper from the setup host's distribution facts - [`a8290eb`](https://github.com/morluto/rea/commit/a8290eb001dcdec33b726779a5f71cd9c65cf107) fix(verify-package): require Hopper readiness only where Linux setup installs it - [`abb451f`](https://github.com/morluto/rea/commit/abb451f4cb23bd10dd83381e296fb58fad6e20a2) Merge remote-tracking branch 'origin/main' into sweep/3422 ### 📊 Changes **12 files changed** (+180 additions, -53 deletions) <details> <summary>View changed files</summary> 📝 `docs/installation.md` (+4 -2) 📝 `scripts/verify-package-discovery.d.mts` (+2 -1) 📝 `scripts/verify-package-discovery.mjs` (+12 -13) 📝 `src/application/Doctor.test.ts` (+1 -1) 📝 `src/application/Doctor.ts` (+1 -1) 📝 `src/application/DoctorDiagnostics.ts` (+2 -2) 📝 `src/application/LinuxHopper.test.ts` (+30 -12) 📝 `src/application/LinuxHopper.ts` (+40 -12) 📝 `src/application/Setup.recovery.test.ts` (+1 -1) 📝 `src/application/SetupHost.ts` (+9 -5) 📝 `src/setupEnvironment.test.ts` (+49 -0) 📝 `tests/evaluation/package/packageSetupSupport.test.ts` (+29 -3) </details> ### 📄 Description ## Summary Fixes #3419. On Linux arm64 hosts, `rea setup` treated automated Hopper installation as supported whenever `/etc/os-release` matched a tested distribution. Every pinned Linux Hopper package is x86_64-only, so on such hosts setup planned and asked for approval of an install that cannot succeed. This change refuses that install up front instead. ## Problem and expected behavior Smallest trigger, on Ubuntu 24.04 aarch64: `rea setup --client codex --install-hopper --json` returned `needs_confirmation` with an `install_hopper` action for `Hopper-6.4.2-Linux-demo.deb`. With `--yes`, it would go on to download that package and run `pkexec apt-get install`. Violated invariant: `hopperSetupSupported` should only be true where the pinned package can be installed. The pinned packages declare `Architecture: amd64` (deb), `x86_64` (RPM lead) and `arch = x86_64` (Arch `.PKGINFO`). Expected behavior: on non-x86_64 Linux, setup should report `needs_human` with a remediation before any download or package-manager call. This is the same path unsupported distributions such as Debian already take, so that recovery path is unchanged. ## Change and scope - **Owning boundary:** `parseLinuxDistribution` / `readLinuxDistribution` now take the host architecture. `hopperSetupSupported` additionally requires it to match `SUPPORTED_RELEASE_ARCHITECTURE` (`x64`). The comment on that constant records how the package metadata was read. - **Consumers:** setup planning, setup preflight, `installLinuxHopper` and `verify-package-discovery.mjs` already read `hopperSetupSupported`. They now inherit the corrected decision with no downstream repair. - **Wiring:** the doctor host passes its injected `architecture`. The setup host takes its Linux distribution from the doctor host, as it already does for `macosVersion`, so planning and doctor share one host-fact owner. The Linux install host takes the same distribution reader from the setup host (`ad47dcce3`, from review), so planning, preflight and installation cannot disagree. The unused default install host on `installLinuxHopper`, which read `process.env` and `process.arch` directly, is removed. - **Remediation text:** the duplicated list of supported hosts in setup and doctor remediation moves to `LINUX_HOPPER_SETUP_HOSTS` and now names x86_64. `docs/installation.md#hopper` is updated to match. - **Package verification (`a8290eb00`, from review):** on Linux, `packageSetupSupport` now requires doctor Hopper readiness only where the automated installer applies (`hopperSetupSupported === true`); macOS is unchanged. This narrows the readiness assertion from #2973: on hosts outside the installer matrix, such as Kali and `ubuntu-24.04-arm`, package verification no longer asserts that the doctor admits the configured `HOPPER_LAUNCHER_PATH` launcher. - **Unchanged:** macOS Hopper setup, REA host support (`supportsReaHost` still accepts arm64 Linux), Ghidra/IDA, and the pinned releases themselves. Contribution scope: a routine fix within existing setup boundaries, so no maintainer scope decision applies. ## Contract and boundary impact - Semantic owner and earliest changed stage: `LinuxHopper.parseLinuxDistribution`, setup/provider admission. - Contribution scope fit and linked maintainer decision: not applicable (routine fix within existing boundaries). - CLI and MCP/tool-catalog contract: no schema change. On non-x86_64 Linux, `setup --install-hopper` now returns `needs_human` with the new remediation instead of `needs_confirmation`. The setup and doctor remediation strings change wording on all hosts. - Provider, bridge, target-format, or platform compatibility: automated Hopper setup is no longer offered on Linux arm64 or other non-x64 architectures. An existing Hopper launcher via `HOPPER_LAUNCHER_PATH` is unaffected. - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details: removes a planned network download and privileged package-manager call on hosts where they cannot succeed. - Generated metadata, package, or installation impact: on `ubuntu-24.04-arm`, package verification now expects `needs_human` for the explicit `--install-hopper` run, because both sides read the same `readLinuxDistribution(process.arch)` decision. On Linux hosts outside the installer matrix (Kali, `ubuntu-24.04-arm`), package verification no longer requires doctor Hopper readiness. Expected effects: - [x] Read existing files or captured data. (`/etc/os-release`, unchanged) - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - **Tests added or updated:** - `LinuxHopper.test.ts`: every tested distribution on `arm64` keeps its package family and REA host support but has `hopperSetupSupported: false`. The x64 cases are unchanged. - `packageSetupSupport.test.ts`: the packaged verifier does not expect automated Hopper on arm64 Ubuntu 24.04, and on Linux it no longer requires Hopper readiness where the installer does not apply (arm64 Ubuntu 24.04, Kali). Both cases fail without the `a8290eb00` change. - `setupEnvironment.test.ts`: the real `systemSetupHost` installs Linux Hopper from the selected doctor host's classification. A supported x64 fixture reaches the (mocked, refused) download; an unsupported arm64 fixture returns `unsupported_host` without any download. - The setup and doctor remediation expectations are updated. - **Base reproduction (executed):** with the new architecture condition replaced by `true` (base behavior), all 7 new cases fail. They pass with it restored. With the install host reading `readLinuxDistribution(process.arch)` directly again, the new `setupEnvironment.test.ts` x64 case fails on this arm64 host; on an x64 host the arm64 case would fail instead (source-derived, not run). - **User-visible CLI output (executed on Ubuntu 24.04.5 LTS aarch64, Node 24.18.1, isolated `HOME`):** ``` # before: npx rea-agents@6.4.0 setup --client codex --install-hopper --json {"status":"needs_confirmation","remediation":"Review the setup plan, then rerun interactively or with --yes.","planned":["install_hopper","configure_client","install_skill"],"applied":[]} # after: node scripts/rea.mjs setup --client codex --install-hopper --json {"status":"needs_human","remediation":"Automated Hopper setup requires an x86_64 host running Ubuntu 24.04+, Fedora 41+, Nobara 44+, Arch Linux, CachyOS, or Omarchy; configure an existing supported provider instead.","planned":["install_hopper","configure_client","install_skill"],"applied":[]} # after, with --yes {"status":"needs_human","remediation":"Automated Hopper setup requires an x86_64 host running …","applied":[]} ``` In the `--yes` run, no file was written under the isolated `HOME`, no `rea-hopper-*` temporary directory was created, and `dpkg -s hopper` reports the package as not installed. I did not run the base build with `--yes`, because it would attempt the real package install. - **Remaining proof gaps:** - Not run on an x86_64 Linux host. That path is covered only by the unchanged x64 unit cases. - Interactive (TTY) setup on arm64 not exercised; source-derived, it uses the same `hopperInstallSupported` gate. - The CI `ubuntu-24.04-arm` package lane has not run yet; the same `npm run verify:package` passes locally on aarch64. ## Validation performed - `npm run test:local -- src/application/LinuxHopper.test.ts src/application/Setup.recovery.test.ts src/application/Doctor.test.ts src/application/Setup.planning.test.ts src/application/Setup.configuration.test.ts src/ghidra/GhidraDoctor.test.ts tests/evaluation/package/packageSetupSupport.test.ts` — 7 files, 156 tests passed - Same two new-test files with the architecture condition replaced by `true` — 7 failed (expected), then restored - `npm run test:local -- src/setupEnvironment.test.ts src/application/LinuxHopper.test.ts` — 2 files, 59 tests passed - Same `setupEnvironment.test.ts` with the install host reading the ambient host again — 1 failed (expected, x64 case on arm64), then restored - `npm run test:local -- tests/evaluation/package/packageSetupSupport.test.ts` — 6 passed; without the `a8290eb00` change, 2 failed (expected) - `npm run test:changed -- --base origin/main` — 30 files, 534 tests passed (on `ad47dcce3` and again on `a8290eb00`) - `npm run check:fast` — typecheck and lint passed - `npm run format:check` — passed - `npm run docs:check` — passed - `npm run build:cached` plus the CLI runs above on Ubuntu 24.04.5 aarch64 — results as shown - `npm run verify:package` on Ubuntu 24.04.5 aarch64, Node 24.18.1 — exit 0 on `dca573dd4`, `ad47dcce3` and `a8290eb00`; all 18 stages complete, including `package discovery` and `setup and uninstall CLI` ## Compatibility, safety, and release - Breaking changes or migration steps: none. On non-x64 Linux, explicit `--install-hopper` now stops with `needs_human` instead of attempting an install that could not succeed. Remediation wording changes. - Real Hopper/Ghidra, browser, or OS coverage: real setup CLI on Ubuntu 24.04 aarch64, without Hopper because no arm64 package exists. Not run on x86_64 Linux or macOS. - Package or release metadata impact: none beyond the CI expectations noted above. - Security, privacy, process, or containment review: reduces privileged package-manager invocations and external downloads on unsupported hosts. No new effects. ## Author readiness  Human owner: @DavidFB-creator - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## 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.  ### Maintainer blocker verification macOS arm64, Node 24.18.0/npm 11.16.0, exact head `abb451f4cb23bd10dd83381e296fb58fad6e20a2`: `npm pack --dry-run --json` passed through prepack (1,671 files, including Linux Hopper/setup outputs). `npm run verify:package` passed archive, install/update, CLI/MCP, setup/uninstall and cleanup checks, including read-only setup planning and preservation of existing Hopper. This run did not verify additional OS hosts. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:09:01 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:44:55 +00:00

[PR #5762] [MERGED] fix(pcap): preserve frames with empty protocol stacks #7043

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

No description provided.

Rows
Columns