[GH-ISSUE #8505] [Design] Detect publisher package drift across Hopper release formats #6629

New issue

Open

opened 2026-11-01 21:12:47 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:47 +00:00

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8505

Before submitting

Searched open and closed issues and pull requests for related discussions.
Reviewed contribution scope; this proposal does not authorize installing or executing analysis engines automatically.
No credentials, private samples, or sensitive target data are included.

Decision needed

Should REA run a scheduled, bounded package-verification check for the current Hopper release across DEB, RPM, Arch and macOS artifacts, separately from provider runtime tests?

Context and evidence

The new installer checklist helps agents investigate failures, but cannot itself detect publisher drift. On 2026-11-01, independently downloaded Hopper 6.6.1 packages showed:

DEB and RPM both match the feed's size/SHA-1 and verify under the pinned PGP publisher.
DEB launcher matches main_exe_hash; RPM launcher does not (#7077).
The signed macOS app requires 12.4, while REA's setup gate accepts 12.0 (#8502).

At source 3842809c371a59609f576a9db8f9c492a3f071e6, .github/workflows/real-hopper-linux.yml uses workflow_dispatch only, and its clean setup job runs on Ubuntu 24.04. That lane establishes its selected host and package when run; it does not continuously establish current RPM/Arch compatibility. Ordinary package verification uses fixtures and is a different claim. This observation does not imply other REA CI coverage is absent.

Expected interaction with targets

Contact official publisher endpoints; read and authenticate downloaded package files; write isolated temporary verification artifacts. Native inspection commands may run, but the downloaded Hopper application and analyzed targets must not execute. This proposal does not install packages or mutate host provider installations.

Options and tradeoffs

Keep deterministic fixtures in ordinary PR checks. Add an opt-in or scheduled publisher check with explicit network, byte, elapsed-time and cleanup bounds. Report external outage, malformed metadata, bad signature, launcher mismatch and incompatible package requirements separately. Never convert a mismatch to a passing check or silently update the trusted identity.

Reuse the production parsers and verification owners, with an independent native package/app observation where needed. Record each claimed format separately. Retain release version, observation time, URLs, package digests, signing identity, observed launcher hash and declared OS/architecture requirements. Do not label package inspection as installed-provider or CLI/MCP runtime coverage.

A manual release checklist is cheaper to implement, but still depends on someone running it. Scheduling downloads adds publisher traffic and infrastructure cost; cadence, artifacts, notification ownership and failure deduplication need a maintainer decision. Avoid opening a fresh issue for every repeat failure of the same release.

Verification available so far

Observed package-verification results and inspected workflow configuration. No new scheduled job or complete per-format runtime matrix was implemented.

Success criteria and open questions

A valid publisher signature with a wrong feed launcher hash fails in the correct category.
A package raising its minimum OS is reported even if its signature and checksum pass.
One format passing does not imply other formats passed; missing coverage is explicit.
HTTP errors and timeouts remain distinguishable from integrity failures.
Temporary resources are released or explicitly retained for cleanup retry.
Decide cadence, responsible notification destination, deduplication, and whether this should remain advisory rather than gate unrelated PRs.

References

#7077: verified Linux vendor discrepancy and download budget.
#8502: signed macOS app requirement differs from REA's fixed floor.
Current manual Linux workflow
Homebrew artifact minimum-OS audit: prior art for comparing declared requirements with downloaded software. It does not establish a particular scheduling policy for REA.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8505 ### Before submitting - [x] Searched open and closed issues and pull requests for related discussions. - [x] Reviewed contribution scope; this proposal does not authorize installing or executing analysis engines automatically. - [x] No credentials, private samples, or sensitive target data are included. ### Decision needed Should REA run a scheduled, bounded package-verification check for the current Hopper release across DEB, RPM, Arch and macOS artifacts, separately from provider runtime tests? ### Context and evidence The new installer checklist helps agents investigate failures, but cannot itself detect publisher drift. On 2026-11-01, independently downloaded Hopper 6.6.1 packages showed: - DEB and RPM both match the feed's size/SHA-1 and verify under the pinned PGP publisher. - DEB launcher matches `main_exe_hash`; RPM launcher does not (#7077). - The signed macOS app requires 12.4, while REA's setup gate accepts 12.0 (#8502). At source `3842809c371a59609f576a9db8f9c492a3f071e6`, `.github/workflows/real-hopper-linux.yml` uses `workflow_dispatch` only, and its clean setup job runs on Ubuntu 24.04. That lane establishes its selected host and package when run; it does not continuously establish current RPM/Arch compatibility. Ordinary package verification uses fixtures and is a different claim. This observation does not imply other REA CI coverage is absent. ### Expected interaction with targets Contact official publisher endpoints; read and authenticate downloaded package files; write isolated temporary verification artifacts. Native inspection commands may run, but the downloaded Hopper application and analyzed targets must not execute. This proposal does not install packages or mutate host provider installations. ### Options and tradeoffs Keep deterministic fixtures in ordinary PR checks. Add an opt-in or scheduled publisher check with explicit network, byte, elapsed-time and cleanup bounds. Report external outage, malformed metadata, bad signature, launcher mismatch and incompatible package requirements separately. Never convert a mismatch to a passing check or silently update the trusted identity. Reuse the production parsers and verification owners, with an independent native package/app observation where needed. Record each claimed format separately. Retain release version, observation time, URLs, package digests, signing identity, observed launcher hash and declared OS/architecture requirements. Do not label package inspection as installed-provider or CLI/MCP runtime coverage. A manual release checklist is cheaper to implement, but still depends on someone running it. Scheduling downloads adds publisher traffic and infrastructure cost; cadence, artifacts, notification ownership and failure deduplication need a maintainer decision. Avoid opening a fresh issue for every repeat failure of the same release. ### Verification available so far Observed package-verification results and inspected workflow configuration. No new scheduled job or complete per-format runtime matrix was implemented. ### Success criteria and open questions - A valid publisher signature with a wrong feed launcher hash fails in the correct category. - A package raising its minimum OS is reported even if its signature and checksum pass. - One format passing does not imply other formats passed; missing coverage is explicit. - HTTP errors and timeouts remain distinguishable from integrity failures. - Temporary resources are released or explicitly retained for cleanup retry. - Decide cadence, responsible notification destination, deduplication, and whether this should remain advisory rather than gate unrelated PRs. ### References - #7077: verified Linux vendor discrepancy and download budget. - #8502: signed macOS app requirement differs from REA's fixed floor. - [Current manual Linux workflow](https://github.com/morluto/rea/blob/3842809c371a59609f576a9db8f9c492a3f071e6/.github/workflows/real-hopper-linux.yml) - [Homebrew artifact minimum-OS audit](https://docs.brew.sh/Cask-Cookbook#choosing-the-minimum-macos-release): prior art for comparing declared requirements with downloaded software. It does not establish a particular scheduling policy for REA.

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:12:47 +00:00

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

No description provided.

Rows
Columns