mirror of
https://github.com/morluto/rea.git
synced 2026-11-09 16:26:36 +00:00
2SinceJulyand2SinceJuly
ca456efcbf
* fix(wasm): admit compatible 1.0.x WABT releases REA_WABT_BIN_DIRECTORY admission compared each --version banner to the literal 1.0.42, so a Homebrew or rolling-distribution WABT that advanced past that build was refused even though wasm-validate, wasm-objdump and wasm2wat accept the same flags and emit the same output shape. Callers had to keep a hand-extracted 1.0.42 tarball alongside the system package. Admission now accepts the release range ^1.0.42 and records the observed banner, matching how the Wakaru adapter already admits compatible builds. The verified release stays the reference: a banner other than 1.0.42 is retained as tool_profile.release and provider.version and the report states that only 1.0.42 was verified. All three tools must report the same release, since one directory is one installation. Managed downloads stay pinned. Fixes #9197 * fix(wasm): bound WABT admission to releases the report schema accepts WABT_ACCEPTED_RANGE was "^1.0.42", which also admits 1.1.0 and later 1.x releases, while wasmArtifactSchema only accepts 1.0.x banners. A configured tool reporting 1.1.0 therefore passed version admission, ran the inspection, and then failed at report parsing. Use the explicit ">=1.0.42 <1.1.0" range so admission and the schema agree, and test the boundary. Also carry the compatible-release warning into both partial-Evidence builders. Previously only successful reports stated that REA verified 1.0.42, so a validation rejection or later read failure under a compatible release silently dropped the uncertainty that a success reports. Share the text through wabtReleaseLimitation so both paths stay aligned. * fix(wasm): stop claiming the 1.0.42 commit for a newer admitted release A caller-supplied 1.0.43 or 1.0.44 was admitted with the observed banner in tool_profile.release, but source_commit still carried the 1.0.42 revision, which is a claim about a build that did not run. Emit null for any release other than the verified 1.0.42; the observed release and each executable digest still identify what actually ran. Also spell the accepted range as it is defined (>=1.0.42 <1.1.0) in the guide and the failure fixture instead of ^1.0.42, which in semver admits 1.1.0. --------- Co-authored-by: 2SinceJuly <202121119+2SinceJuly@users.noreply.github.com>