morluto/rea

Fork 0

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

[GH-ISSUE #7077] Linux Hopper setup fails for current vendor release: fixed 120 s download deadline exceeded and feed main_exe_hash does not match the published launcher #4266

New issue

Open

opened 2026-10-31 00:48:17 +00:00 by bsakaguchi · 8 comments

bsakaguchi commented

2026-10-31 00:48:17 +00:00

Owner

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

Summary

rea setup --install-hopper on Linux cannot succeed for the current Hopper release, for two independent reasons:

The vendor download from hopperapp.com streams at a rate that exceeds REA's fixed 120 s package-download deadline from our network, and the deadline cannot be raised (values above 120,000 ms are rejected).
The official release feed advertises a main_exe_hash that does not match the launcher in the currently published demo packages, so verification would fail with integrity even when the download completes. The package itself does verify against the pinned publisher key, so this appears to be stale feed metadata rather than a version handling bug on REA's side.

Algumas observations: in both failed runs the structured result returned only the generic code: "download_failed" remediation ("REA could not download or unpack...") with no underlying reason, which made diagnosis slow; the actual failure (timeout / which URL) is not surfaced.

Environment

rea-agents 6.7.0 via npx -y rea-agents@latest
Fedora Linux 43 x86_64, Node.js v24.22.1
Command: npx -y rea-agents@latest setup --client opencode --skill --install-hopper --yes --json

Evidence

1. Vendor download rate vs REA's fixed deadline

dist/application/HopperDownload.js caps the deadline:

// downloadHopperPackage
const timeoutMs = options.timeoutMs ?? 120_000;
if (!Number.isSafeInteger(timeoutMs) || timeoutMs < 1 || timeoutMs > 120_000)
    throw new RangeError("Invalid Hopper response time budget");

Measured with curl under the same UA REA sends (rea-installer):

Feed (.../include/files-api.php?request=releases&public=true): HTTP 200 quickly.
Package (https://www.hopperapp.com:443/downloader/public/Hopper-6.6.0-Linux-demo.rpm, 32,261,798 bytes): completes only after ~132 s (~245 KB/s sustained).

The download therefore never completes inside the 120 s cap, and every setup attempt ends in the generic download_failed. Notes: 120 s is also the maximum accepted value, and there is no environment override for this deadline (REA_HOPPER_STARTUP_TIMEOUT_MS covers provider startup only). The feed/key metadata budgets are separate and fine (RELEASE_METADATA_TIMEOUT_MS = 10_000, both URLs respond well within it).

2. Feed `main_exe_hash` does not match the released packages

The feed (public=true) reports for all three Linux families (Ubuntu / Mint, Fedora, Arch) of 6.6.0:

file_length = 32261798, file_hash (SHA-1) = 933aa2502550923a865f79e837ba403494c4b4b3 (matches the RPM we downloaded byte-for-byte)
main_exe_hash = b2271008fb82bf14cfae5c3644cdde2b11fc6804bd7c99d67032ec1b1942d53c
detached signature verifies Good with the official key; imported primary fingerprint matches the pinned 7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD (signed via subkey 868AD58E3275680D224CC9EC36D2884BC4DB1C33)

But the actual launcher in that verified package does not match the advertised main_exe_hash:

$ rpm -qp --nosignature --nodigest --qf "%{FILEDIGESTALGO}\n[%{FILENAMES}\t%{FILEDIGESTS}\n]" Hopper-6.6.0-Linux-demo.rpm
8
/opt/hopper/bin/Hopper	4d6c23b6ab4f50b811bb454956f56871737976d6655a44098ba1978baad12947

# direct check after extracting the same archive
$ sha256sum opt/hopper/bin/Hopper
4d6c23b6ab4f50b811bb454956f56871737976d6655a44098ba1978baad12947  opt/hopper/bin/Hopper

No file inside the package hashes to the advertised b2271008... value. So REA's post-authentication check

The signed rpm package launcher SHA-256 4d6c... differs from the release main_exe_hash b227...

would reject this release even when the download succeeds. The signature being valid for the whole package while main_exe_hash is stale suggests the vendor rebuilt/repacked the demo without updating the feed's main_exe_hash.

Suggestions

Make the package-download deadline configurable (e.g., REA_HOPPER_DOWNLOAD_TIMEOUT_MS) or retry-with-backoff instead of surfacing a timeout as the generic download_failed.
Surface the underlying failure reason (timeout vs release_metadata vs integrity, per URL) in the structured setup result; the generic code obscured both findings.
Consider messaging the vendor relationship: with a stale main_exe_hash, Hopper setup fails for everyone regardless of network speed until the feed is corrected.

Happy to provide the exact curl commands / extraction steps used, or re-run anything on this host.

As a related data point, the same vendor retry-flow pattern showed up in #3209 (completion reported as download_failed when a later step fails); here the download itself always fails because the vendor feeds the bytes slower than the hard deadline.

Originally created by @kystudioau on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7077 ## Summary `rea setup --install-hopper` on Linux cannot succeed for the current Hopper release, for two independent reasons: 1. The vendor download from `hopperapp.com` streams at a rate that exceeds REA's fixed 120 s package-download deadline from our network, and the deadline cannot be raised (values above 120,000 ms are rejected). 2. The official release feed advertises a `main_exe_hash` that does not match the launcher in the currently published demo packages, so verification would fail with `integrity` even when the download completes. The package itself does verify against the pinned publisher key, so this appears to be stale feed metadata rather than a version handling bug on REA's side. Algumas observations: in both failed runs the structured result returned only the generic `code: "download_failed"` remediation (`"REA could not download or unpack..."`) with no underlying reason, which made diagnosis slow; the actual failure (timeout / which URL) is not surfaced. ## Environment - rea-agents 6.7.0 via `npx -y rea-agents@latest` - Fedora Linux 43 x86_64, Node.js v24.22.1 - Command: `npx -y rea-agents@latest setup --client opencode --skill --install-hopper --yes --json` ## Evidence ### 1. Vendor download rate vs REA's fixed deadline `dist/application/HopperDownload.js` caps the deadline: ```js // downloadHopperPackage const timeoutMs = options.timeoutMs ?? 120_000; if (!Number.isSafeInteger(timeoutMs) || timeoutMs < 1 || timeoutMs > 120_000) throw new RangeError("Invalid Hopper response time budget"); ``` Measured with curl under the same UA REA sends (`rea-installer`): - Feed (`.../include/files-api.php?request=releases&public=true`): HTTP 200 quickly. - Package (`https://www.hopperapp.com:443/downloader/public/Hopper-6.6.0-Linux-demo.rpm`, 32,261,798 bytes): completes only after ~132 s (~245 KB/s sustained). The download therefore never completes inside the 120 s cap, and every setup attempt ends in the generic `download_failed`. Notes: 120 s is also the maximum accepted value, and there is no environment override for this deadline (`REA_HOPPER_STARTUP_TIMEOUT_MS` covers provider startup only). The feed/key metadata budgets are separate and fine (`RELEASE_METADATA_TIMEOUT_MS = 10_000`, both URLs respond well within it). ### 2. Feed `main_exe_hash` does not match the released packages The feed (`public=true`) reports for all three Linux families (`Ubuntu / Mint`, `Fedora`, `Arch`) of 6.6.0: - `file_length` = 32261798, `file_hash` (SHA-1) = `933aa2502550923a865f79e837ba403494c4b4b3` (matches the RPM we downloaded byte-for-byte) - `main_exe_hash` = `b2271008fb82bf14cfae5c3644cdde2b11fc6804bd7c99d67032ec1b1942d53c` - detached `signature` verifies **Good** with the official key; imported primary fingerprint matches the pinned `7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD` (signed via subkey `868AD58E3275680D224CC9EC36D2884BC4DB1C33`) But the actual launcher in that verified package does not match the advertised `main_exe_hash`: ``` $ rpm -qp --nosignature --nodigest --qf "%{FILEDIGESTALGO}\n[%{FILENAMES}\t%{FILEDIGESTS}\n]" Hopper-6.6.0-Linux-demo.rpm 8 /opt/hopper/bin/Hopper 4d6c23b6ab4f50b811bb454956f56871737976d6655a44098ba1978baad12947 # direct check after extracting the same archive $ sha256sum opt/hopper/bin/Hopper 4d6c23b6ab4f50b811bb454956f56871737976d6655a44098ba1978baad12947 opt/hopper/bin/Hopper ``` No file inside the package hashes to the advertised `b2271008...` value. So REA's post-authentication check ``` The signed rpm package launcher SHA-256 4d6c... differs from the release main_exe_hash b227... ``` would reject this release even when the download succeeds. The signature being valid for the whole package while `main_exe_hash` is stale suggests the vendor rebuilt/repacked the demo without updating the feed's `main_exe_hash`. ## Suggestions - Make the package-download deadline configurable (e.g., `REA_HOPPER_DOWNLOAD_TIMEOUT_MS`) or retry-with-backoff instead of surfacing a timeout as the generic `download_failed`. - Surface the underlying failure reason (timeout vs `release_metadata` vs `integrity`, per URL) in the structured setup result; the generic code obscured both findings. - Consider messaging the vendor relationship: with a stale `main_exe_hash`, Hopper setup fails for everyone regardless of network speed until the feed is corrected. Happy to provide the exact curl commands / extraction steps used, or re-run anything on this host. As a related data point, the same vendor retry-flow pattern showed up in #3209 (completion reported as `download_failed` when a later step fails); here the download itself always fails because the vendor feeds the bytes slower than the hard deadline.

bsakaguchi commented

2026-10-31 00:48:18 +00:00

Author

Owner

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

两个问题都确认是真实的：120 s 硬上限既不能配置也没有环境变量覆盖，对慢速网络完全无解；main_exe_hash 与包内 launcher 不一致则是 vendor 侧 stale feed，REA 的完整性校验逻辑本身没错，但结果就是所有用户都会被卡住。认可你的方向：(1) 把包下载超时做成可配置（REA_HOPPER_DOWNLOAD_TIMEOUT_MS 或 retry-with-backoff），默认值可以保留但不应封顶 120 s；(2) 结构化 setup 结果里把失败原因细分（timeout / release_metadata / integrity，带具体 URL），别再用泛化的 download_failed 掩盖。额外建议：验签通过但 main_exe_hash 不匹配时，可以在错误信息里显式提示"包签名有效、疑似 feed 元数据过期"，帮用户快速判断是 vendor 问题而非供应链风险；同时把 #3209 的同类错误分类一并纳入，避免每类失败各自为政。

@XinwangTao commented on GitHub (Oct 25, 2026): 两个问题都确认是真实的：120 s 硬上限既不能配置也没有环境变量覆盖，对慢速网络完全无解；main_exe_hash 与包内 launcher 不一致则是 vendor 侧 stale feed，REA 的完整性校验逻辑本身没错，但结果就是所有用户都会被卡住。认可你的方向：(1) 把包下载超时做成可配置（REA_HOPPER_DOWNLOAD_TIMEOUT_MS 或 retry-with-backoff），默认值可以保留但不应封顶 120 s；(2) 结构化 setup 结果里把失败原因细分（timeout / release_metadata / integrity，带具体 URL），别再用泛化的 download_failed 掩盖。额外建议：验签通过但 main_exe_hash 不匹配时，可以在错误信息里显式提示"包签名有效、疑似 feed 元数据过期"，帮用户快速判断是 vendor 问题而非供应链风险；同时把 #3209 的同类错误分类一并纳入，避免每类失败各自为政。

bsakaguchi commented

2026-10-31 00:48:18 +00:00

Author

Owner

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

Two independent blockers here — thanks for separating them. On the deadline: fixed 120s is clearly too tight for vendor CDNs; making the deadline configurable (env var or --timeout flag) with a sane default that still fails fast is the right direction. On the hash mismatch: since the package verifies against the pinned publisher key, treating main_exe_hash as a soft warning with an explicit integrity caveat (rather than a hard failure) would let installs proceed while still surfacing drift — or auto-refresh the feed hash when the publisher signature is intact. Either way, the failure mode should tell the user which part (network vs integrity) blocked the install.

@XinwangTao commented on GitHub (Oct 25, 2026): Two independent blockers here — thanks for separating them. On the deadline: fixed 120s is clearly too tight for vendor CDNs; making the deadline configurable (env var or --timeout flag) with a sane default that still fails fast is the right direction. On the hash mismatch: since the package verifies against the pinned publisher key, treating main_exe_hash as a soft warning with an explicit integrity caveat (rather than a hard failure) would let installs proceed while still surfacing drift — or auto-refresh the feed hash when the publisher signature is intact. Either way, the failure mode should tell the user which part (network vs integrity) blocked the install.

bsakaguchi commented

2026-10-31 00:48:18 +00:00

Author

Owner

@morluto commented on GitHub (Oct 26, 2026):

Related evidence: #3578 independently documents the Fedora 6.6.0 RPM signature, header, and launcher hash mismatch. That report also observed matching Ubuntu deb and Arch launcher hashes, so the verified package mismatch should not be generalized to all three formats from the shared feed value alone. I have consolidated the Fedora report here; the download timeout and integrity diagnosis remain distinct. No vendor feed or installation was rerun in this triage.

@morluto commented on GitHub (Oct 26, 2026): Related evidence: #3578 independently documents the Fedora 6.6.0 RPM signature, header, and launcher hash mismatch. That report also observed matching Ubuntu deb and Arch launcher hashes, so the verified package mismatch should not be generalized to all three formats from the shared feed value alone. I have consolidated the Fedora report here; the download timeout and integrity diagnosis remain distinct. No vendor feed or installation was rerun in this triage.

bsakaguchi commented

2026-10-31 00:48:18 +00:00

Author

Owner

@Dobydoo commented on GitHub (Oct 29, 2026):

Fedora 44 datapoint, plus a correction to one workaround claim

Environment: Fedora 44 (kernel 7.2.13-200.fc44.x86_64, x86_64), Node v24.18.0, npm 11.16.0, rea-agents 6.7.0. Same two digests as every report above; deterministic across retries.

1. `rea-agents@6.8.0` (current npm `latest`) does not change this

Checked the published tarball rather than assuming. dist/application/LinuxHopperPublisher.js in 6.8.0 still has the identical equality check:

if (mainExeHash !== release.main_exe_hash)
    return err(new HopperReleaseError("integrity", `The signed ${family} package launcher SHA-256 ${mainExeHash} differs from the release main_exe_hash ${release.main_exe_hash}.`));

#packageLauncherHash is unchanged for the rpm branch (%{FILEDIGESTS} on /opt/hopper/bin/Hopper, requiring %{FILEDIGESTALGO} == 8). So the top-level remediation "update REA" remains non-actionable at time of writing; 6.8.0 reproduces, it does not fix.

2. The mismatch is a single stripped ELF section, not a different build

Section-by-section comparison of opt/hopper/bin/Hopper from the 6.6.0 .deb (b2271008…) vs the .rpm (4d6c23b6…):

section	deb vs rpm
`.text` `.rodata` `.data` `.dynamic` `.dynsym` `.dynstr` `.init` `.fini`	byte-identical
`.comment`	deb only

.comment in the deb contains GCC: (Ubuntu 10.5.0-4ubuntu2.1) 10.5.0 and Ubuntu clang version 18.1.3 (1ubuntu1). The rpm launcher is the same compiled image with the section header table one entry shorter (31 vs 32 sections) and 152 fewer bytes (9,555,136 vs 9,555,288). That is consistent with the Fedora build being produced by the same compile and one post-link section-strip step, which is why the feed's single shared main_exe_hash disagrees.

Also confirmed the Arch pkg.tar.xz launcher is byte-identical to the deb launcher at b2271008…, so 2 of 3 channels agree and only Fedora diverges.

3. Correction: the launcher-path workaround does work

#3578 concluded that pointing HOPPER_LAUNCHER_PATH at the hash-matching .deb launcher still fails rea doctor's hopper-version with integrity. That is true for a bare launcher, but not for the whole path. inspectLauncher accepts a launcher if #cachedPackage finds a retained signed entry under <cache>/<launcher-sha256> — it only reaches the family-specific feed comparison on cache_missing.

So a working, check-preserving recovery on Fedora 44 is:

Extract the official .deb payload (launcher hash b2271008…, matches the feed) to ~/.local/share/rea/hopper/.
Seed ~/.cache/rea/hopper-releases/b2271008…/ with archive (the signed package), public-key.asc (official key), and release.json ({"format":"rea-signed-hopper-release-v1","family":"arch","release":<feed row>}).
Use the Arch feed row, not Ubuntu: #packageLauncherHash verifies deb through dpkg-deb, which is absent on Fedora, so a deb-family cache entry fails with verification_unavailable. Arch verifies with plain tar and yields the same b2271008… launcher.

Result — rea doctor:

- name: hopper            ok: true  /home/doby/.local/share/rea/hopper/bin/Hopper
- name: hopper-version    ok: true
    reported_release_version: 6.6.0
    launcher_sha256: b2271008fb82bf14cfae5c3644cdde2b11fc6804bd7c99d67032ec1b1942d53c
    primary_fingerprint: 7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD
    source: signed_package_cache
- name: hopper-demo-runtime  ok: true   (after dnf install xorg-x11-server-Xvfb xorg-x11-xauth)

and rea analyze ./smoke --provider hopper returns procedure_count: 11, segment_count: 4, with upstream_analysis_profile.provider.version = launcher-sha256:b2271008….

I am not proposing this as a fix — it requires hand-seeding the cache, and the real fix is still a per-family main_exe_hash in the vendor feed, or the pinned-dual-hash acceptance used by #933. Surfacing it because it shows the verification logic itself is sound: nothing here needs weakening, and the unsupported_hopper_build / integrity distinction is behaving correctly.

4. Download deadline is also still real here

The 32,261,798-byte rpm took ~98 s from this network on a 300 s curl budget, i.e. close to your fixed 120 s package deadline. Not the failure I hit, but it corroborates the second half of this issue.

@Dobydoo commented on GitHub (Oct 29, 2026): **Fedora 44 datapoint, plus a correction to one workaround claim** Environment: Fedora 44 (kernel `7.2.13-200.fc44.x86_64`, x86_64), Node `v24.18.0`, npm `11.16.0`, `rea-agents` **6.7.0**. Same two digests as every report above; deterministic across retries. ### 1. `rea-agents@6.8.0` (current npm `latest`) does not change this Checked the published tarball rather than assuming. `dist/application/LinuxHopperPublisher.js` in 6.8.0 still has the identical equality check: ```js if (mainExeHash !== release.main_exe_hash) return err(new HopperReleaseError("integrity", `The signed ${family} package launcher SHA-256 ${mainExeHash} differs from the release main_exe_hash ${release.main_exe_hash}.`)); ``` `#packageLauncherHash` is unchanged for the `rpm` branch (`%{FILEDIGESTS}` on `/opt/hopper/bin/Hopper`, requiring `%{FILEDIGESTALGO}` == `8`). So the top-level remediation "update REA" remains non-actionable at time of writing; 6.8.0 reproduces, it does not fix. ### 2. The mismatch is a single stripped ELF section, not a different build Section-by-section comparison of `opt/hopper/bin/Hopper` from the 6.6.0 `.deb` (`b2271008…`) vs the `.rpm` (`4d6c23b6…`): | section | deb vs rpm | | --- | --- | | `.text` `.rodata` `.data` `.dynamic` `.dynsym` `.dynstr` `.init` `.fini` | byte-identical | | `.comment` | **deb only** | `.comment` in the deb contains `GCC: (Ubuntu 10.5.0-4ubuntu2.1) 10.5.0` and `Ubuntu clang version 18.1.3 (1ubuntu1)`. The rpm launcher is the same compiled image with the section header table one entry shorter (31 vs 32 sections) and 152 fewer bytes (9,555,136 vs 9,555,288). That is consistent with the Fedora build being produced by the same compile and one post-link section-strip step, which is why the feed's single shared `main_exe_hash` disagrees. Also confirmed the Arch `pkg.tar.xz` launcher is byte-identical to the deb launcher at `b2271008…`, so 2 of 3 channels agree and only Fedora diverges. ### 3. Correction: the launcher-path workaround *does* work #3578 concluded that pointing `HOPPER_LAUNCHER_PATH` at the hash-matching `.deb` launcher still fails `rea doctor`'s `hopper-version` with `integrity`. That is true for a bare launcher, but not for the whole path. `inspectLauncher` accepts a launcher if `#cachedPackage` finds a retained signed entry under `<cache>/<launcher-sha256>` — it only reaches the family-specific feed comparison on `cache_missing`. So a working, check-preserving recovery on Fedora 44 is: 1. Extract the official `.deb` payload (launcher hash `b2271008…`, matches the feed) to `~/.local/share/rea/hopper/`. 2. Seed `~/.cache/rea/hopper-releases/b2271008…/` with `archive` (the signed package), `public-key.asc` (official key), and `release.json` (`{"format":"rea-signed-hopper-release-v1","family":"arch","release":<feed row>}`). 3. Use the **Arch** feed row, not Ubuntu: `#packageLauncherHash` verifies `deb` through `dpkg-deb`, which is absent on Fedora, so a deb-family cache entry fails with `verification_unavailable`. Arch verifies with plain `tar` and yields the same `b2271008…` launcher. Result — `rea doctor`: ``` - name: hopper ok: true /home/doby/.local/share/rea/hopper/bin/Hopper - name: hopper-version ok: true reported_release_version: 6.6.0 launcher_sha256: b2271008fb82bf14cfae5c3644cdde2b11fc6804bd7c99d67032ec1b1942d53c primary_fingerprint: 7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD source: signed_package_cache - name: hopper-demo-runtime ok: true (after dnf install xorg-x11-server-Xvfb xorg-x11-xauth) ``` and `rea analyze ./smoke --provider hopper` returns `procedure_count: 11`, `segment_count: 4`, with `upstream_analysis_profile.provider.version` = `launcher-sha256:b2271008…`. I am not proposing this as a fix — it requires hand-seeding the cache, and the real fix is still a per-family `main_exe_hash` in the vendor feed, or the pinned-dual-hash acceptance used by #933. Surfacing it because it shows the verification logic itself is sound: nothing here needs weakening, and the `unsupported_hopper_build` / `integrity` distinction is behaving correctly. ### 4. Download deadline is also still real here The 32,261,798-byte rpm took ~98 s from this network on a 300 s curl budget, i.e. close to your fixed 120 s package deadline. Not the failure I hit, but it corroborates the second half of this issue.

bsakaguchi commented

2026-10-31 00:48:19 +00:00

Author

Owner

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

Thanks for the Fedora 44 datapoint and especially the section-level comparison — pinning the mismatch to a single stripped section (with 2 of 3 channels agreeing on b2271008…) makes the per-family main_exe_hash fix clearly correct, and the corrected cache-seeding workaround confirms the verification logic itself is sound. One thought for REA's side: since the package signature verifies against the pinned key and the launcher lives inside that same signed package, accepting a dual-hash (feed hash or in-package hash) when the publisher signature is intact — along the lines of #933 — would avoid hard-failing every Fedora user while the vendor feed is stale. And with ~98 s on your network, the 120 s deadline is uncomfortably close even on decent connections, so a configurable timeout with a higher default still seems warranted.

@XinwangTao commented on GitHub (Oct 29, 2026): Thanks for the Fedora 44 datapoint and especially the section-level comparison — pinning the mismatch to a single stripped section (with 2 of 3 channels agreeing on b2271008…) makes the per-family main_exe_hash fix clearly correct, and the corrected cache-seeding workaround confirms the verification logic itself is sound. One thought for REA's side: since the package signature verifies against the pinned key and the launcher lives inside that same signed package, accepting a dual-hash (feed hash or in-package hash) when the publisher signature is intact — along the lines of #933 — would avoid hard-failing every Fedora user while the vendor feed is stale. And with ~98 s on your network, the 120 s deadline is uncomfortably close even on decent connections, so a configurable timeout with a higher default still seems warranted.

bsakaguchi referenced this issue

2026-10-31 01:12:16 +00:00

[PR #4274] [MERGED] fix(lifecycle): preserve observations and cleanup ownership #6153

bsakaguchi commented

2026-11-01 21:11:09 +00:00

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

Fresh package-level verification on 2026-11-01 confirms that the Fedora launcher/feed mismatch persists in Hopper 6.6.1.

Downloaded the current official DEB and RPM selected by the public feed, using REA's rea-installer user agent. Both packages match their advertised size and SHA-1, and both detached signatures pass the source verifyDetachedPgpSignature under primary fingerprint 7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD (signing subkey 868AD58E3275680D224CC9EC36D2884BC4DB1C33).

Package	Bytes	Feed SHA-1	Extracted launcher SHA-256
`Hopper-6.6.1-Linux-demo.deb`	35,749,234	`a2c28339b768609dc7766869f51d25a38b49fd2a`	`74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999`
`Hopper-6.6.1-Linux-demo.rpm`	32,261,874	`8796f901812c0067bfe6154fa188d25b7fc9e24b`	`b41e67e7fa30f25216db83ab8f986ea8fa3fb7e87761cb98c90cd96dc97bc376`

The feed advertises the DEB launcher hash for both channels. Independent RPM-header decoding finds digest algorithm 8 (SHA-256) and the same b41e67e7… value for /opt/hopper/bin/Hopper; this agrees with the payload extracted using macOS bsdtar. ELF comparison finds .comment only in the DEB, a differing .shstrtab, and identical other shared file-backed sections, including .text and .rodata. This is consistent with a post-link stripping difference; the actual publisher build process remains unknown.

At source revision 245a581818ab13694fa438a06e39898ce03ab206, LinuxHopperPublisher.#verifyArchive rejects this disagreement before package-manager execution. Correct per-package vendor metadata remains the preferred resolution; these observations do not justify disabling verification or accepting the DEB hash for RPM bytes.

Limits: package inspection and source-verifier execution on Darwin arm64 / Node v25.1.0; no full Fedora setup or Hopper runtime was executed. Arch 6.6.1 was not downloaded. The two concurrent curl downloads finished in 9.425 s (DEB) and 14.415 s (RPM), so this run did not reproduce the slow-download failure. Source still caps the package deadline at 120 s. Feed and key returned HTTP 200 with REA's actual headers; a default-curl 403 is not evidence that REA itself is blocked.

Follow-up: 3842809c3 adds installer checks and troubleshooting guidance for host support, package/feed disagreement, download failures, and runtime readiness. This is a documentation change; it does not correct the vendor metadata or change the download deadline. Bazzite-specific setup guidance and the remaining container verification are tracked in #8500.

@morluto commented on GitHub (Nov 1, 2026): Fresh package-level verification on 2026-11-01 confirms that the Fedora launcher/feed mismatch persists in **Hopper 6.6.1**. Downloaded the current official DEB and RPM selected by the [public feed](https://www.hopperapp.com/include/files-api.php?request=releases&public=true), using REA's `rea-installer` user agent. Both packages match their advertised size and SHA-1, and both detached signatures pass the source `verifyDetachedPgpSignature` under primary fingerprint `7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD` (signing subkey `868AD58E3275680D224CC9EC36D2884BC4DB1C33`). | Package | Bytes | Feed SHA-1 | Extracted launcher SHA-256 | | --- | ---: | --- | --- | | `Hopper-6.6.1-Linux-demo.deb` | 35,749,234 | `a2c28339b768609dc7766869f51d25a38b49fd2a` | `74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999` | | `Hopper-6.6.1-Linux-demo.rpm` | 32,261,874 | `8796f901812c0067bfe6154fa188d25b7fc9e24b` | `b41e67e7fa30f25216db83ab8f986ea8fa3fb7e87761cb98c90cd96dc97bc376` | The feed advertises the DEB launcher hash for both channels. Independent RPM-header decoding finds digest algorithm 8 (SHA-256) and the same `b41e67e7…` value for `/opt/hopper/bin/Hopper`; this agrees with the payload extracted using macOS `bsdtar`. ELF comparison finds `.comment` only in the DEB, a differing `.shstrtab`, and identical other shared file-backed sections, including `.text` and `.rodata`. This is consistent with a post-link stripping difference; the actual publisher build process remains unknown. At source revision [`245a581818ab13694fa438a06e39898ce03ab206`](https://github.com/morluto/rea/tree/245a581818ab13694fa438a06e39898ce03ab206), `LinuxHopperPublisher.#verifyArchive` rejects this disagreement before package-manager execution. Correct per-package vendor metadata remains the preferred resolution; these observations do not justify disabling verification or accepting the DEB hash for RPM bytes. **Limits:** package inspection and source-verifier execution on Darwin arm64 / Node v25.1.0; no full Fedora setup or Hopper runtime was executed. Arch 6.6.1 was not downloaded. The two concurrent curl downloads finished in 9.425 s (DEB) and 14.415 s (RPM), so this run did not reproduce the slow-download failure. Source still caps the package deadline at 120 s. Feed and key returned HTTP 200 with REA's actual headers; a default-curl 403 is not evidence that REA itself is blocked. Follow-up: [3842809c3](https://github.com/morluto/rea/commit/3842809c3) adds installer checks and troubleshooting guidance for host support, package/feed disagreement, download failures, and runtime readiness. This is a documentation change; it does not correct the vendor metadata or change the download deadline. Bazzite-specific setup guidance and the remaining container verification are tracked in #8500.

bsakaguchi commented

2026-11-01 21:11:09 +00:00

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

Related research and follow-up issues from the provider audit:

#8503 reproduces lost HTTP status in the macOS setup path; the Linux-specific fix in #7183 does not cover that adapter.
#8502 verifies the current signed macOS app requires 12.4 while setup accepts 12.0. Artifact integrity and host compatibility need separate checks.
#8505 proposes monitoring current publisher/package drift; deterministic fixtures and an old Ubuntu pass do not establish today's Fedora package.

For download design, Playwright's browser downloader preserves HTTP status and URL in failures, and its browser installation docs describe a configurable download timeout. Playwright passes a socket timeout to its downloader; REA's AbortSignal budget covers the total download. These budgets should not be treated as interchangeable.

For REA, the proposed improvement is to preserve typed failure facts and provide an explicit bounded download budget with actionable recovery. Do not copy automatic retries indiscriminately: retries cannot fix a valid-signature/feed-hash disagreement, and integrity verification should remain a hard gate. No timeout change or retry behavior was implemented by this audit, and the earlier live downloads here did not reproduce the reported slow network.

@morluto commented on GitHub (Nov 1, 2026): Related research and follow-up issues from the provider audit: - #8503 reproduces lost HTTP status in the **macOS** setup path; the Linux-specific fix in #7183 does not cover that adapter. - #8502 verifies the current signed macOS app requires 12.4 while setup accepts 12.0. Artifact integrity and host compatibility need separate checks. - #8505 proposes monitoring current publisher/package drift; deterministic fixtures and an old Ubuntu pass do not establish today's Fedora package. For download design, Playwright's [browser downloader](https://github.com/microsoft/playwright/blob/main/packages/playwright-core/src/server/registry/oopDownloadBrowserMain.ts) preserves HTTP status and URL in failures, and its [browser installation docs](https://playwright.dev/docs/browsers#install-behind-a-firewall-or-a-proxy) describe a configurable download timeout. Playwright passes a socket timeout to its downloader; REA's AbortSignal budget covers the total download. These budgets should not be treated as interchangeable. For REA, the proposed improvement is to preserve typed failure facts and provide an explicit bounded download budget with actionable recovery. Do not copy automatic retries indiscriminately: retries cannot fix a valid-signature/feed-hash disagreement, and integrity verification should remain a hard gate. No timeout change or retry behavior was implemented by this audit, and the earlier live downloads here did not reproduce the reported slow network.

bsakaguchi commented

2026-11-04 04:56:16 +00:00

Author

Owner

@XinwangTao commented on GitHub (Nov 4, 2026):

Appreciate the fresh 6.6.1 verification — pinning the mismatch to post-link section stripping across two releases makes the per-family feed hash the clear root cause. Agree with the audit's boundaries: retries can't fix a valid-signature/feed-hash disagreement, so keeping integrity a hard gate is right, and #8505's drift monitoring is the sensible long-term fix.

On the timeout half, I'd support treating the 120 s cap as a total-budget problem and moving to a stall/socket-based timeout (the #7150 direction) rather than just raising the number — a slow-but-progressing download and a dead connection are different failures, and only the latter should fail fast. That also keeps the Playwright socket-timeout vs AbortSignal distinction you called out: budget the transfer, not the wall clock.

Small concrete idea for #8505: the existing verification path already computes in-package hash vs feed hash — logging that diff on mismatch (and on success) would give drift-detection signal for free, without a separate monitoring service.

@XinwangTao commented on GitHub (Nov 4, 2026): Appreciate the fresh 6.6.1 verification — pinning the mismatch to post-link section stripping across two releases makes the per-family feed hash the clear root cause. Agree with the audit's boundaries: retries can't fix a valid-signature/feed-hash disagreement, so keeping integrity a hard gate is right, and #8505's drift monitoring is the sensible long-term fix. On the timeout half, I'd support treating the 120 s cap as a total-budget problem and moving to a stall/socket-based timeout (the #7150 direction) rather than just raising the number — a slow-but-progressing download and a dead connection are different failures, and only the latter should fail fast. That also keeps the Playwright socket-timeout vs AbortSignal distinction you called out: budget the transfer, not the wall clock. Small concrete idea for #8505: the existing verification path already computes in-package hash vs feed hash — logging that diff on mismatch (and on success) would give drift-detection signal for free, without a separate monitoring service.

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

No description provided.

Rows
Columns

[GH-ISSUE #7077] Linux Hopper setup fails for current vendor release: fixed 120 s download deadline exceeded and feed main_exe_hash does not match the published launcher #4266

Summary

Environment

Evidence

1. Vendor download rate vs REA's fixed deadline

2. Feed main_exe_hash does not match the released packages

Suggestions

1. rea-agents@6.8.0 (current npm latest) does not change this

2. The mismatch is a single stripped ELF section, not a different build

3. Correction: the launcher-path workaround does work

4. Download deadline is also still real here

2. Feed `main_exe_hash` does not match the released packages

1. `rea-agents@6.8.0` (current npm `latest`) does not change this