mirror of
https://github.com/alexmi256/rea-agent-docker.git
synced 2026-11-07 09:45:59 -10:00
main
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Hermes Agent
|
a58f16224c |
deps: Hopper 6.6.2 from the vendor's signed feed (no REA move)
`make check-updates` failed with BEHIND-REA on both Hopper rows: the vendor's
publisher-signed release feed moved its Ubuntu/Mint entry from Hopper 6.6.1 to
6.6.2 on 2026-11-06 16:22 UTC. REA 6.8.0 admits a Linux Hopper only when the
installed launcher is the feed's *current* main_exe_hash, so the old pin was
already wrong - and the build layer would have refused outright ("Hopper feed
moved: Hopper-6.6.2-Linux-demo.deb is no longer Hopper-6.6.1-Linux-demo.deb").
rea-agents itself is current: 6.8.0 is the newest npm release *and* the newest
github tag (v6.8.0, 2026-10-25), and its release notes list nothing pending for
Hopper beyond the feed-admission rule already implemented. So nothing else moved:
same REA_VERSION, same Node 24.22.1, same bundled skill (v49 / 229 tools), same
Ghidra 12.1.4, same helper tools (unicorn stays held at 2.1.2 because pwntools
4.15.0 excludes 2.1.3/2.1.4; Node 24.22.2, frida 17.26.1, uv 0.13.7,
supergateway 4.2.1, mitmproxy 12.3.1, pwndbg 2026.10.28 and Ghidra 12.2 are
newer upstream but wait for the next REA release per docs/UPDATES.md).
Re-pinned to the feed's row:
HOPPER_DEMO_VERSION 6.6.1 -> 6.6.2
HOPPER_DEB_SHA1 a2c28339..-> 9b46788160ba0b37f9050e0aa23a1372b3ecff53
HOPPER_DEB_BYTES 35749234 -> 35749280
HOPPER_LAUNCHER_SHA256 74b51599..-> 226800f154d766664bad5c45912f3a606ffa894316f97464f3c37f01fab5fb82
None of it was taken on trust: the .deb was downloaded (35,749,280 bytes,
sha1 9b467881...), its detached PGP signature verified against the vendor key
whose primary fingerprint is 7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD - the one
REA pins as HOPPER_LINUX_PRIMARY_FINGERPRINT - and opt/hopper/bin/Hopper hashed
out of the unpacked package (226800f1...), which is what the feed claims. The
build re-checks all four against the live feed, verifies bytes + SHA-1 and the
installed launcher, and bakes the signed evidence under
/home/rea/.cache/rea/hopper-releases/226800f1.../ (archive, release.json,
public-key.asc) so admission works offline; `rea doctor --provider hopper --json`
reports hopper-version healthy, reported_release_version 6.6.2,
source signed_package_cache.
Verified: scripts/build-all.sh (all four rebuilt; Hopper layer 3 min, the rest
cache hits), scripts/verify-all-engines.sh - all 121/0/3, ghidra 109/0/8, hopper
102/0/7, ida 94/0/11, 0 failures, exit 0 on every image; runs 20261107T091717Z /
20261107T092924Z / 20261107T094115Z / 20261107T094312Z. Counts are identical to
the 6.6.1 round; docs/verify-engines.txt regenerated and the sweep recorded in
docs/VERIFICATION.md. `make check-updates` is back to 0 actionable / 0 unknown /
0 unverifiable.
Docs that name the shipped Hopper build follow the pin (README, ARCHITECTURE,
MULTIARCH, BYO-LICENSES, TROUBLESHOOTING, vendor/README, the checker's header
comment); the 6.6.1 and 6.6.0 records in docs/VERIFICATION.md keep the versions
they actually ran.
|
||
|
Hermes Agent
|
7c890ab632 |
deps: Hopper 6.6.1 from the vendor's signed feed (no REA move)
`make check-updates` failed with BEHIND-REA on both Hopper rows: the vendor's
publisher-signed release feed moved its Ubuntu/Mint entry from Hopper 6.6.0 to
6.6.1 on 2026-10-29. REA 6.8.0 admits a Linux Hopper only when the installed
launcher is the feed's *current* main_exe_hash, so the old pin was already
wrong - and the build layer would have refused outright ("Hopper feed moved:
Hopper-6.6.1-Linux-demo.deb is no longer Hopper-6.6.0-Linux-demo.deb").
rea-agents itself is current (6.8.0 is the newest npm release *and* the newest
github tag), so nothing else moved: same REA_VERSION, same Node 24.22.1, same
bundled skill (v49 / 229 tools), same Ghidra.
Re-pinned to the feed's row:
HOPPER_DEMO_VERSION 6.6.0 -> 6.6.1
HOPPER_DEB_SHA1 575efccf.. -> a2c28339b768609dc7766869f51d25a38b49fd2a
HOPPER_DEB_BYTES 35748722 -> 35749234
HOPPER_LAUNCHER_SHA256 b2271008.. -> 74b51599fa2b72cf927aa9d089c7046ee0942fb1c29eb0750ac166b3dff97999
The launcher digest was not taken on trust: the package was downloaded and
unpacked and opt/hopper/bin/Hopper hashed out of it (74b51599...), which is what
the feed claims. The build then re-checks all four against the live feed,
verifies bytes + SHA-1 and the installed launcher, and bakes the signed evidence
under /home/rea/.cache/rea/hopper-releases/74b51599.../ so admission works
offline; `rea doctor --provider hopper --json` reports hopper-version healthy,
reported_release_version 6.6.1, source signed_package_cache.
Also: .env.example carried NODE_VERSION=24.22.0, which 6.8.0's engines.node
(^24.22.1) refuses - compose-based builds would have produced a runtime REA
will not start. Aligned with the Dockerfile at 24.22.1.
Verified: scripts/build-all.sh (all four), scripts/verify-all-engines.sh -
all 121/0/3, ghidra 109/0/8, hopper 102/0/7, ida 94/0/11, 0 failures, exit 0 on
every image; runs 20261031T092059Z / 20261031T093304Z / 20261031T094453Z /
20261031T094650Z. Counts are identical to the 6.8.0 round; docs/verify-engines.txt
regenerated. `make check-updates` is back to 0 actionable / 0 unknown.
|
||
|
Hermes Agent
|
ffaff66505 |
deps: REA 6.8.0 (+ Node 24.22.1), and the admissions that moved with it
Upstream: https://github.com/morluto/rea/releases/tag/rea-agents-6.8.0 Check: make check-updates -> 0 actionable / 6 pending / 0 unknown Harness: scripts/verify-all-engines.sh 121/0/3 · 109/0/8 · 102/0/7 · 94/0/11 REA 6.8.0 changes two things this image has to follow: - engines.node is now ^22.23.4 || ^24.22.1 || >=26.12.1, so the 24.22.0 runtime that 6.7.0 accepted is *refused*. NODE_VERSION moves to 24.22.1 in the same commit, in the Dockerfile and in the compose default. - the bundled skill is v49 with 229 MCP tools (was v42 / 207), read from the shipped dist/mcp-catalog.json rather than the release notes. No engine admission moved: GhidraReleasePolicy.ts is byte-identical (12.1.4, Java 21) and Hopper is still the vendor feed's 6.6.0 demo, so the engine pins are untouched and the harness re-proved both providers. Two checks had to change shape, and both got stricter: - binwalk/unblob left CapabilityInventory's remediation prose for structured defineToolRequirement() entries in src/contracts/firmware/firmwareToolRequirements.ts. scrape_rea now reads those first and falls back to the prose, so both rows keep showing the admitted value instead of printing `ok` with nothing verified. - extract-artifact lost its second positional (REA picks the destination and reports output_root). The harness now asserts containment_verified, coverage complete, cleanup verified, non-empty created artifacts, and that the reported files exist under the reported root - one check more per image than the exit-status check it replaces. Docs regenerated for this run: docs/verify-engines.txt, docs/verify-summary.txt, the size table (make sizes), and the skill/tool counts in README, HERMES-MCP, IMAGES, ARCHITECTURE and UPDATES. |
||
|
Hermes Agent
|
9d78e670b4 |
deps: REA 6.7.0, and Hopper admission through the vendor's signed feed
morluto/rea rea-agents-6.7.0 is the current npm release (the pin was 6.5.0).
This is not only a version string: REA 6.6.0 replaced Hopper's fixed
launcher-digest allowlist (SUPPORTED_RELEASES / SUPPORTED_HOPPER_SHA256) with the
vendor's publisher-signed release feed, whose only Linux entry is the *current*
demo. The pinned Hopper 6.4.2 build is refused outright by 6.6.0+, so the admitted
build is now Hopper 6.6.0 (launcher b2271008...).
Dockerfile:
* REA_VERSION 6.5.0 -> 6.7.0; frida 17.23.3 -> 17.24.1
* the Hopper layer reads the vendor feed and fails when it no longer matches the
pins (HOPPER_DEMO_VERSION / _SHA1 / _BYTES / _LAUNCHER_SHA256), verifies the
downloaded package (byte length + SHA-1) and the installed launcher digest,
and retains the signed evidence (feed row + vendor public key + package bytes)
under REA's own cache path, so the launcher is admitted without network access
* records the admitted digest at /usr/local/share/rea/hopper-launcher.sha256
for the harness to assert against
checker (scripts/check-updates.py):
* Ghidra admission source was renamed (GhidraInstallationPolicy.ts ->
GhidraReleasePolicy.ts in the 6.6.x line) - repointed
* Hopper admission is read from the vendor feed rather than REA's source, which
no longer carries either table. Both engine rows had silently stopped
verifying; they verify again rather than merely reporting ok
harness:
* the Hopper launcher-digest check asserts the digest this build admits and
skips with a reason for a vendor/licensed package, which REA admits by its own
publisher evidence instead
compose / env / docs:
* 6.7.0 tag suffix everywhere, Hopper moved to 6.6.0, refreshed size table
(Hopper's delta grew ~92 MB -> ~128 MB: the retained signed evidence
duplicates the installed .deb), UPDATES/VERIFICATION/BYO-LICENSES/TROUBLESHOOTING
rewritten for the feed gate, Kuna recorded as an accepted gap (caller-supplied
provider, like IDA), and a stale NODE_VERSION default in compose corrected
Checks run:
* make check-updates -> 34 rows: 0 actionable, 0 unverifiable, exit 0
* scripts/verify-all-engines.sh (all four images, full harness) -> 0 failures,
exit 0 on every image: all 120/0/3, ghidra 108/0/8, hopper 101/0/7,
ida 93/0/11. Report: docs/verify-engines.txt (runs 20261019T014730Z,
...T015922Z, ...T021101Z, ...T021249Z), summary: docs/verify-summary.txt
* the four images were built locally as ghcr.io/alexmi256/rea-agent[-ghidra|
-hopper|-ida]:6.7.0-linux-amd64 and the in-image harness confirms REA reports
hopper launcher-sha256:b2271008... in every Hopper analysis profile
Upstream: https://github.com/morluto/rea/releases/tag/rea-agents-6.7.0
|
||
|
Hermes Agent
|
e584319eb6 |
deps: bump to current upstream, and ship the Wakaru engine REA advertises
Policy note first, because it explains the shape of this commit: pins follow rea-agents, and nothing is bumped on its own schedule. This round is the explicit exception - the checker found a real capability gap (REA 6.5.0 advertises recover_javascript_sources while the image shipped nothing for it, so the operation reported provider_missing). docs/UPDATES.md now states the rule and names the only two exceptions: a BEHIND-REA drift, and a MISSING capability. Wakaru 1.14.0 (REA's JavaScript source-recovery engine): - Installed from the official release asset, not npm: REA resolves and fingerprints the executable itself, and the npm route's node_modules/.bin entry is a Node shim it rejects. REA_WAKARU_COMMAND is absolute, as REA requires, and the image also carries util-linux prlimit (REA's resource limiter for it). - The pin is two values on purpose: WAKARU_VERSION and WAKARU_LINUX_X64_SHA256. The digest is REA's own audited value for that asset (docs/javascript-recovery.md in the pinned release), so the build fails if the bytes ever differ. - 13 new harness checks. Five assert REA's admission rules on the binary (absolute path, readable+executable, the exact "wakaru <semver>" banner, the audited digest, prlimit). Eight run the operation: a minified bundle fixture is recovered and the Evidence is asserted on schema fields (provider wakaru, status complete, failed 0, module decompiled, and the fingerprinted digest proving REA ran the audited build), the published module file is checked, and the recovered tree is then analysed with analyze-javascript-application. - The checker gained a digest row comparing our pin with the digest REA documents, and its wakaru row is no longer hardcoded as missing. Bumps applied: Node 24.21.0 to 24.22.0, frida 17.23.2 to 17.23.3, uv 0.13.0 to 0.13.1, supergateway 4.1.0 to 4.2.0, plus Wakaru. Unicorn stays at 2.1.2, and the build proved why: pip refuses unicorn 2.1.4 with ResolutionImpossible because pwntools 4.15.0 declares "unicorn !=2.1.3, !=2.1.4". The constraint is now recorded in the Dockerfile comment, in the docs, and in a HELD map in the checker, which reports such components as "held on <pin>: <reason>" instead of as an available update. Two build defects found and fixed rather than worked around: - The Node layer failed with "sha256sum: no properly formatted checksum lines found": /var/cache/rea-dl is a shared build cache keyed by filename, and it held the PREVIOUS version's SHASUMS256.txt under a version-less name, so the new tarball's checksum line was never found. Cached filenames are now version-qualified (the same hazard was latent for the Wakaru tarball, fixed too), and the stale file was deliberately left in place so the fix had to work without a cache clean. This is documented as a trap in docs/UPDATES.md. - Neither failure could reach GHCR: publishing only runs after verification. Checker semantics now match the policy: exit 1 means the image is wrong NOW (BEHIND-REA, MISSING, MISMATCH) or a new REA release exists (NEW REA - the trigger to move everything). Merely-newer upstream releases are listed as waiting for the next release and do not fail the weekly job, which is the difference between a useful reminder and a permanently red run. Verification: full per-engine sweep on all four rebuilt images, 0 failures - all 120/0/3, ghidra 108/0/8, hopper 101/0/7, ida 93/0/11, exit 0 everywhere. Full log (kernel string redacted) in docs/verify-engines.txt; image sizes in docs/IMAGES.md refreshed from make sizes. |
||
|
Hermes Agent
|
e23e8bbcc8 |
build: bump rea-agents to 6.5.0
Upstream published rea-agents 6.5.0 (npm `latest` and the GitHub release `rea-agents-6.5.0`, 2026-10-14), one minor ahead of the 6.4.0 this repo pinned. Only REA changed. Every other pin was re-checked against what 6.5.0 itself declares, and all already matched: * Node 24.21.0 — 6.5.0 engines are ^22.19.0 || ^24.11.0 || >=26.0.0, and its SQLite inspector needs 24.x >= 24.15. * frida 17.23.2 — 6.5.0 lists it as `optionalDependencies`, installed with `--allow-scripts=frida` and symlinked into the package, as before. * Ghidra 12.1.4, Hopper 6.4.2 (the Linux build 6.5.0 still admits, digest- checked), WABT 1.0.42, sigrok-cli 0.7.2 + libsigrokdecode, TShark 4.x, mitmproxy 12.2.3, Apktool 2.12.x, jadx-headless-mcp 0.7.1, unblob 26.6.4. The image's bundled workflow skill moves with the package: v37 -> v42, and the MCP catalog 170 -> 207 tools (153 CLI commands). Docs that quoted those numbers are updated, and the stale "this family is on repository main, not in the release" notes are rewritten — 6.5.0 *is* the release that ships those families. Harness: 6.5.0 exposes command families that 6.4.0 left on main (frida, sqlite, wasm, go, pcap, signal), so `check_rea` now runs them for real instead of skipping — the `all` image went from 14 skips to 3. That exposed one latent harness defect: `sigrok decoder inventory` asserted `uart` appeared in the decoder catalog's *default* page, but the catalog is sorted and paginated (50 of 111), so `uart` sorts past it. The command was fine; the check now searches with `inspect-signal-decoders --query uart`. Also newly green on this bump: RISC-V64 and PowerPC ELF searches, which 6.4.0 refused with `unsupported ELF architecture`. Verification (full harness, one run per image, twice — the second pass after the sigrok fix confirmed the same counts and populated `image:` in the summaries): all 107 passed / 0 failed / 3 skipped exit 0 ghidra 95 passed / 0 failed / 8 skipped exit 0 hopper 88 passed / 0 failed / 7 skipped exit 0 ida 80 passed / 0 failed / 11 skipped exit 0 Records regenerated in docs/verify-engines.txt and docs/verify-summary.txt (platform line redacted as before). scripts/verify.sh, scripts/build.sh and CI now pass REA_IMAGE_ID to the harness, so the summary names the image it verified instead of reporting "unknown" (the harness's own fallback, /etc/rea/image-id, is hidden by the ./config bind mount). |
||
|
Hermes Agent
|
e6a1d1d1b9 |
publish the four engine images to GHCR on push, and document pulling them
Registry: - The build job now runs on push to main (and dispatch), not just dispatch, and publishes each engine image to ghcr.io/<owner>/rea-agent[-ghidra|-hopper|-ida] under both <REA_VERSION>-linux-amd64 and latest. PRs skip it (a fork token cannot push packages). Publishing happens after the harness and the foreign-uid check pass, so a broken image never reaches the registry. - The published tag is derived from the Dockerfile's REA_VERSION (no drift), and the OCI label org.opencontainers.image.source is set from the repo URL - that label is what links the package to the repository and lets it inherit the repo's (public) visibility. It is baked last so adding labels never invalidates the cached engine layers. - docker/login-action@v4 (v3 is node20 - same deprecation trap as the others). One source of truth for image names: - New scripts/image-name.sh resolves an engine to its image, honouring REA_IMAGE / REA_GHIDRA_IMAGE / REA_HOPPER_IMAGE / REA_IDA_IMAGE from .env and falling back to a plain local name. build.sh, verify.sh (new --engine flag), verify-all-engines.sh and the Makefile all use it, so what you build, verify and pull are never different names. Previously a local build tagged rea-agent-ghidra while compose asked for the GHCR name. - compose and .env.example now default to the GHCR coordinates, so works with no build at all; rebuilding from source replaces the same name instead of creating a second one. - Makefile: pull / pull-all / sizes work on pulled or built images alike. Docs: README quick start split into pull vs build; docs/IMAGES.md gains the GHCR table, air-gapped transfer, per-fork publishing steps and the permissions note; TROUBLESHOOTING covers pull failures and resolver mismatches. CI validate now fails if the published names, compose defaults, resolver output and docs drift apart, or if the tag disagrees with the Dockerfile. |
||
|
Hermes Agent
|
9744abb126 |
fix: entrypoint must survive a uid the image does not know
The first CI run failed in the verification step (not the build - the image built
and was tagged in ~6 min on the runner, which had 102 GB free, so my earlier
'out of disk' guess was wrong):
[rea-agent] loaded overrides from /etc/rea/rea.env
mkdir: cannot create directory '/tmp/rea/home': Permission denied
CI started the container as the runner's uid, so $HOME was not writable; the
writable-HOME fallback then tried to create /tmp/rea/home, but /tmp/rea was
mode 755 owned by the image user, and `set -e` killed the entrypoint. Reproduced
locally with `docker run --user 12345:12345`.
- Dockerfile: the scratch dir is now mode 1777 (like /tmp, so users can only
remove their own files).
- entrypoint.sh: the fallback tries $REA_HOME_FALLBACK, then $TMPDIR/home, then
`mktemp -d`, and if all fail it warns and continues instead of aborting -
refusing to start hides the real problem behind an entrypoint failure.
- CI: a build-job step runs the image as uid 12345 and fails if it sees a
permission error, so this cannot regress silently.
- Verified on all four images: `rea --version` works as uid 12345 (6.4.0) and the
matching-uid path is unchanged; /tmp/rea is drwxrwxrwt.
|
||
|
Hermes Agent
|
28ba580064 |
Fix engine-awareness gaps the per-engine harness exposed
- Healthcheck kept the old unconditional Ghidra/Hopper checks (left over from the
first patch), so every single-engine image reported itself unhealthy. Removed
them; the healthcheck now checks only the engine(s) it declares, and the
harness asserts the healthcheck itself ('healthy:') for each image, shallow and
deep.
- Engine paths moved from /etc/rea to /usr/local/share/rea: compose mounts the
user's ./config over /etc/rea, which shadowed the baked marker and env file.
- The harness adopts engine.env for its own checks (and supplies inert defaults),
so a single-engine image skips instead of aborting under set -u.
- .dockerignore no longer excludes vendor/*.deb and vendor/ida/*: git still never
commits them, but the build context must contain them or the documented
licensed-Hopper / baked-IDA paths silently do nothing. Verified with a probe
build that the files now reach the context.
- verify-all-engines.sh: QUICK=0 made ${QUICK:+--quick} always expand, so the
sweep silently ran the fast profile. Use an empty default.
- docs: sizes are measured now, MULTIARCH/vendor/compose docs follow the
per-engine services.
|
||
|
Hermes Agent
|
596f7befb3 |
Per-engine images: one Dockerfile, four images (all/ghidra/hopper/ida)
- REA_ENGINE=(all|ghidra|hopper|ida) selects the native engine; the engine layers are built LAST so every earlier layer is shared cache across the four variants (docs/ARCHITECTURE.md layer map updated). - Each image declares itself: /etc/rea/engine (marker), /etc/rea/engine.env (only the paths it needs, plus REA_ANALYSIS_PROVIDER for single-engine images), and a /usr/local/bin/rea wrapper that sources engine.env - so `docker exec -i <ctr> rea mcp` finds the engine with no compose environment, and an image without Ghidra never advertises GHIDRA_INSTALL_DIR. - healthcheck, entrypoint and the verification harness are engine-aware: they read /etc/rea/engine and SKIP (with a reason) checks for engines the image does not ship. One harness verifies all four images. - compose: one service per engine (rea-agent, rea-ghidra, rea-hopper, rea-ida) with per-engine env and home volumes; engine-agnostic HTTP bridge sidecar; IDA overlay applies to both rea-agent and rea-ida. - scripts: build.sh --engine, build-all.sh, verify-all-engines.sh; Makefile gains per-engine build/up/verify/sizes targets; CI matrix (ghidra on push, all four on workflow_dispatch). - fix: runtime user creation is now tolerant of Ubuntu's stock uid/gid 1000 (groupadd failed with 'GID 1000 already exists' when REA_UID was unset), and build.sh passes REA_UID/REA_GID through from the environment/.env. - docs: new IMAGES.md (per-engine guide) and ida-variants.md (IDA vs IDA Pro: one program, four licence plans; which edition can drive REA and how); README/HERMES-MCP/BYO-LICENSES/ARCHITECTURE/TROUBLESHOOTING updated. |
||
|
Hermes Agent
|
bcd0e22286 |
Pin the Hopper build REA accepts, fix npm/dotnet/cross-toolchain installs, make the harness release-aware
- Hopper: install the Linux demo package REA 6.4.0 pins (6.4.2, launcher digest 0294ced1...) instead of the newest vendor build, so `rea doctor --provider hopper` reports healthy; derive the filename from REA's own dist at build time, verify size + sha1. - frida: npm 11 blocks install scripts, so the optional dependency was being silently skipped; install it with --allow-scripts and link it into REA's tree (verified: getLocalDevice() returns the local system). - ilspycmd: net6.0 app on a .NET 8 runtime -> DOTNET_ROLL_FORWARD=Major. - cross toolchains: add libc6-dev-*-cross (crt1.o/-lc were missing, so no non-x86-64 fixture could be built). - compose: never define REA_* settings with empty defaults (REA rejects empty strings with configuration_invalid) - optional knobs load from config/rea.env via env_file; ship that template. - harness: release-aware check_rea/check_rea_json (skip families the installed REA release does not expose), fixtures fix (-fno-strip), MCP probe picks an engine-free tool that the served release actually advertises. |
||
|
Hermes Agent
|
ba296cd09a |
rea-agent: Docker image + compose stack for Reverse Engineer Anything
Brings the REA MCP server and its full analysis toolchain into one linux/amd64 image: Ghidra 12.1.4 (multi-architecture), Hopper 6.5.0 demo, bring-your-own IDA/JEB, pwntools/pwndbg, binwalk+unblob, tshark, sigrok-cli, mitmproxy, WABT, jadx/apktool/adb, .NET+ILSpy, Chrome/Playwright, Frida, qemu-user/wine/cross toolchains, plus the stdio and Streamable HTTP MCP surfaces and an in-image verification harness. |