morluto/rea

Fork 0

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

[GH-ISSUE #8138] [Bug] Hopper 6.6.1 Fedora RPM launcher still mismatches the feed main_exe_hash; deb launcher matches (REA 6.8.0) #4682

New issue

Open

opened 2026-10-31 00:52:25 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:52:25 +00:00

Owner

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

Area

Setup, packaging, or upgrade

Observed behavior

On Fedora, rea setup --install-hopper cannot succeed for the current Hopper release 6.6.1 (published 2026-10-29 16:47:03 UTC). It fails after download and publisher verification with integrity_mismatch:

status: needs_human
code:   integrity_mismatch
remediation: The signed rpm package launcher SHA-256 b41e67e7fa30f25216db83ab8f986ea8fa3fb7e87761cb98c90cd96dc97bc376
  differs from the release main_exe_hash 74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999.
  The Hopper download failed integrity verification. Retry setup; if it repeats, update REA before installing.

I ran it twice; the two hashes are identical both times, so this is not transient. rea-agents@latest is 6.8.0, so the "update REA" remediation is not actionable on the current release.

The new fact relative to the 6.6.0 reports (#3578, #7077) is that for 6.6.1 the Ubuntu deb launcher matches the feed field exactly, and only the Fedora RPM differs — the two packages ship different builds:

6.6.1 demo package	bytes	package SHA-1 vs feed `file_hash`	launcher `/opt/hopper/bin/Hopper` SHA-256 (size)
`Hopper-6.6.1-Linux-demo.deb`	35,749,234	`a2c28339b768609dc7766869f51d25a38b49fd2a` = feed ✓	`74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999` (9,555,288) — equals feed `main_exe_hash`
`Hopper-6.6.1-Linux-demo.rpm`	32,261,874	`8796f901812c0067bfe6154fa188d25b7fc9e24b` = feed ✓	`b41e67e7fa30f25216db83ab8f986ea8fa3fb7e87761cb98c90cd96dc97bc376` (9,555,136) — differs

Fedora feed row (public=true): version=6.6.1, file_length=32261874, file_hash=8796f901812c0067bfe6154fa188d25b7fc9e24b, main_exe_hash=74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999, publicKeyFingerprint=7c2d73bafaf5b9a710a69da1a26df815099b1bcd.

So the RPM is authentic (byte length and SHA-1 match the feed exactly; REA's own signature stage passed, since it reached the launcher-hash comparison) — only the vendor's declared main_exe_hash fails to describe the launcher inside their own Fedora package.

A second, distinct symptom appears when the RPM is installed manually and selected through HOPPER_LAUNCHER_PATH instead of through setup:

$ HOPPER_LAUNCHER_PATH=/opt/hopper/bin/Hopper rea doctor --provider hopper --json
- name: hopper             ok: true   /opt/hopper/bin/Hopper
- name: hopper-demo-runtime ok: true  strategy=direct; socket_directory=/tmp/.X11-unix; system_python=loadable
- name: hopper-version     ok: false  config_drift
    reason: unsupported_hopper_build
    message: The selected Hopper launcher does not match an authenticated cached release or the official current Linux demo.

$ rea analyze /usr/bin/ls --json
{"error":"Analysis failed","code":"provider_unavailable",
 "message":"The selected Hopper launcher does not match an authenticated cached release or the official current Linux demo."}

Hopper itself is present and runnable (rpm -q hopper → hopper-6.6.1-1.x86_64; ldd /opt/hopper/bin/Hopper resolves all shared libraries; xorg-x11-server-Xvfb installed), so the failure is admission only.

Reproduction

Fedora 44 x86_64, Node v24.22.2, rea-agents 6.8.0 via npx -y rea-agents@latest. Reproduced twice with identical hashes.

npx -y rea-agents@latest setup --client pi --install-hopper --yes --json → integrity_mismatch with the two hashes above (the download completed within budget on this network; the failure stage is the post-download launcher comparison).

Fetch the feed and the two packages, then compare the launcher inside each:

curl -A 'Mozilla/5.0' -o Hopper-6.6.1-Linux-demo.rpm https://www.hopperapp.com/downloader/public/Hopper-6.6.1-Linux-demo.rpm
curl -A 'Mozilla/5.0' -o Hopper-6.6.1-Linux-demo.deb https://www.hopperapp.com/downloader/public/Hopper-6.6.1-Linux-demo.deb
sha1sum Hopper-6.6.1-Linux-demo.rpm   # 8796f901812c0067bfe6154fa188d25b7fc9e24b (feed file_hash)
sha1sum Hopper-6.6.1-Linux-demo.deb   # a2c28339b768609dc7766869f51d25a38b49fd2a (feed file_hash)
rpm2cpio Hopper-6.6.1-Linux-demo.rpm | cpio -idm --quiet && sha256sum ./opt/hopper/bin/Hopper
ar x Hopper-6.6.1-Linux-demo.deb && tar -xzf data.tar.gz ./opt/hopper/bin/Hopper && sha256sum ./opt/hopper/bin/Hopper

Results are the two launcher digests in the table above.

Install the RPM (dnf install -y ./Hopper-6.6.1-Linux-demo.rpm xorg-x11-server-Xvfb), export HOPPER_LAUNCHER_PATH=/opt/hopper/bin/Hopper, then run rea doctor --provider hopper --json and rea analyze /usr/bin/ls --json → outputs above.

Arch for 6.6.1: NOT_ENOUGH_INFO — I did not download or unpack the Arch package in this report, so I cannot state whether its launcher matches.

Expected behavior

The vendor's per-family main_exe_hash should identify that family's installed launcher, so REA should admit the authenticated Fedora RPM or report the discrepancy without blocking every Fedora user.

Source-derived (not executed): #cachedPackage in LinuxHopperPublisher compares release.value.main_exe_hash !== digest before verifying the retained archive, so seeding the offline cache with the genuine 6.6.1 Fedora row still cannot admit the RPM launcher — the row itself names the deb build. Only a corrected row would pass, which is the same per-family-metadata fix the 6.6.0 thread converged on.

Impact and scope

Observed: on dnf-family hosts, Hopper is unusable with REA 6.8.0 for the current vendor release through both routes — automated setup (integrity_mismatch) and manual HOPPER_LAUNCHER_PATH admission (unsupported_hopper_build → provider_unavailable at analysis time). Verification logic is behaving correctly; the blocking input is vendor metadata.

Untested scope left unknown: whether any 6.6.1 sub-release or a licensed (non-demo) Fedora package matches, and whether other REA releases besides 6.8.0 change the outcome.

Related reports for the earlier release: #3578 (closed, 6.6.0 RPM) and #7077 (open, 6.6.0). Filing separately because those cover 6.6.0 and predate the 6.6.1 publication, and because 6.6.1 adds the deb-matches/RPM-differs datapoint plus the manual-install admission symptom.

Originally created by @gimclick on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8138 ### Area Setup, packaging, or upgrade ### Observed behavior On Fedora, `rea setup --install-hopper` cannot succeed for the **current** Hopper release 6.6.1 (published 2026-10-29 16:47:03 UTC). It fails after download and publisher verification with `integrity_mismatch`: ``` status: needs_human code: integrity_mismatch remediation: The signed rpm package launcher SHA-256 b41e67e7fa30f25216db83ab8f986ea8fa3fb7e87761cb98c90cd96dc97bc376 differs from the release main_exe_hash 74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999. The Hopper download failed integrity verification. Retry setup; if it repeats, update REA before installing. ``` I ran it twice; the two hashes are identical both times, so this is not transient. `rea-agents@latest` is 6.8.0, so the "update REA" remediation is not actionable on the current release. The new fact relative to the 6.6.0 reports (#3578, #7077) is that for **6.6.1 the Ubuntu deb launcher matches the feed field exactly, and only the Fedora RPM differs** — the two packages ship different builds: | 6.6.1 demo package | bytes | package SHA-1 vs feed `file_hash` | launcher `/opt/hopper/bin/Hopper` SHA-256 (size) | |---|---|---|---| | `Hopper-6.6.1-Linux-demo.deb` | 35,749,234 | `a2c28339b768609dc7766869f51d25a38b49fd2a` = feed ✓ | `74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999` (9,555,288) — **equals feed `main_exe_hash`** | | `Hopper-6.6.1-Linux-demo.rpm` | 32,261,874 | `8796f901812c0067bfe6154fa188d25b7fc9e24b` = feed ✓ | `b41e67e7fa30f25216db83ab8f986ea8fa3fb7e87761cb98c90cd96dc97bc376` (9,555,136) — **differs** | Fedora feed row (`public=true`): `version=6.6.1`, `file_length=32261874`, `file_hash=8796f901812c0067bfe6154fa188d25b7fc9e24b`, `main_exe_hash=74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999`, `publicKeyFingerprint=7c2d73bafaf5b9a710a69da1a26df815099b1bcd`. So the RPM is authentic (byte length and SHA-1 match the feed exactly; REA's own signature stage passed, since it reached the launcher-hash comparison) — only the vendor's declared `main_exe_hash` fails to describe the launcher inside their own Fedora package. A second, distinct symptom appears when the RPM is installed manually and selected through `HOPPER_LAUNCHER_PATH` instead of through setup: ``` $ HOPPER_LAUNCHER_PATH=/opt/hopper/bin/Hopper rea doctor --provider hopper --json - name: hopper ok: true /opt/hopper/bin/Hopper - name: hopper-demo-runtime ok: true strategy=direct; socket_directory=/tmp/.X11-unix; system_python=loadable - name: hopper-version ok: false config_drift reason: unsupported_hopper_build message: The selected Hopper launcher does not match an authenticated cached release or the official current Linux demo. $ rea analyze /usr/bin/ls --json {"error":"Analysis failed","code":"provider_unavailable", "message":"The selected Hopper launcher does not match an authenticated cached release or the official current Linux demo."} ``` Hopper itself is present and runnable (`rpm -q hopper` → `hopper-6.6.1-1.x86_64`; `ldd /opt/hopper/bin/Hopper` resolves all shared libraries; `xorg-x11-server-Xvfb` installed), so the failure is admission only. ### Reproduction Fedora 44 x86_64, Node v24.22.2, `rea-agents` 6.8.0 via `npx -y rea-agents@latest`. Reproduced twice with identical hashes. 1. `npx -y rea-agents@latest setup --client pi --install-hopper --yes --json` → `integrity_mismatch` with the two hashes above (the download completed within budget on this network; the failure stage is the post-download launcher comparison). 2. Fetch the feed and the two packages, then compare the launcher inside each: ```bash curl -A 'Mozilla/5.0' -o Hopper-6.6.1-Linux-demo.rpm https://www.hopperapp.com/downloader/public/Hopper-6.6.1-Linux-demo.rpm curl -A 'Mozilla/5.0' -o Hopper-6.6.1-Linux-demo.deb https://www.hopperapp.com/downloader/public/Hopper-6.6.1-Linux-demo.deb sha1sum Hopper-6.6.1-Linux-demo.rpm # 8796f901812c0067bfe6154fa188d25b7fc9e24b (feed file_hash) sha1sum Hopper-6.6.1-Linux-demo.deb # a2c28339b768609dc7766869f51d25a38b49fd2a (feed file_hash) rpm2cpio Hopper-6.6.1-Linux-demo.rpm | cpio -idm --quiet && sha256sum ./opt/hopper/bin/Hopper ar x Hopper-6.6.1-Linux-demo.deb && tar -xzf data.tar.gz ./opt/hopper/bin/Hopper && sha256sum ./opt/hopper/bin/Hopper ``` Results are the two launcher digests in the table above. 3. Install the RPM (`dnf install -y ./Hopper-6.6.1-Linux-demo.rpm xorg-x11-server-Xvfb`), export `HOPPER_LAUNCHER_PATH=/opt/hopper/bin/Hopper`, then run `rea doctor --provider hopper --json` and `rea analyze /usr/bin/ls --json` → outputs above. Arch for 6.6.1: NOT_ENOUGH_INFO — I did not download or unpack the Arch package in this report, so I cannot state whether its launcher matches. ### Expected behavior The vendor's per-family `main_exe_hash` should identify that family's installed launcher, so REA should admit the authenticated Fedora RPM or report the discrepancy without blocking every Fedora user. Source-derived (not executed): `#cachedPackage` in `LinuxHopperPublisher` compares `release.value.main_exe_hash !== digest` before verifying the retained archive, so seeding the offline cache with the **genuine** 6.6.1 Fedora row still cannot admit the RPM launcher — the row itself names the deb build. Only a corrected row would pass, which is the same per-family-metadata fix the 6.6.0 thread converged on. ### Impact and scope Observed: on dnf-family hosts, Hopper is unusable with REA 6.8.0 for the current vendor release through both routes — automated setup (`integrity_mismatch`) and manual `HOPPER_LAUNCHER_PATH` admission (`unsupported_hopper_build` → `provider_unavailable` at analysis time). Verification logic is behaving correctly; the blocking input is vendor metadata. Untested scope left unknown: whether any 6.6.1 sub-release or a licensed (non-demo) Fedora package matches, and whether other REA releases besides 6.8.0 change the outcome. Related reports for the earlier release: #3578 (closed, 6.6.0 RPM) and #7077 (open, 6.6.0). Filing separately because those cover 6.6.0 and predate the 6.6.1 publication, and because 6.6.1 adds the deb-matches/RPM-differs datapoint plus the manual-install admission symptom.

bsakaguchi referenced this issue

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

[PR #4774] [CLOSED] fix(ghidra): recognize OutOfMemoryError beyond the diagnostic budget #6404

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

No description provided.

Rows
Columns