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.
GitHub read the licence as 'Other' because the MIT text was followed by a long
third-party appendix. The appendix now lives in docs/THIRD-PARTY-NOTICES.md
(expanded with the full installed-licence table and an explicit 'not included'
section) and LICENSE is the canonical MIT text only. README points at it.
Hermes Agent