fix(parser): raise MAX_SLICE_LEN to 256MB — large wasip2 components sign (#164, unbreaks release) - #213
Merged
Conversation
…sign (#164) The real #164 bug — my earlier "stale" close (#192) was premature; #192 only *surfaced* it by making wsc-cli.wasm signing a hard requirement. The 2026-08-05 release then failed at "Sign WASM Files": wsc-component.wasm (3.96MB) signed fine, but wsc-cli.wasm (full CLI, large embedded core module) hit "Parse error". Root cause: Section::deserialize rejects any section whose payload exceeds MAX_SLICE_LEN (was 16MB). A wasm COMPONENT's embedded core-module section for a full wasm32-wasip2 CLI exceeds 16MB. Reproduced with a synthetic >16MB-section module (was ParseError; signs+verifies at 256MB). Raise the bound to 256MB — generous for any realistic component, still bounds a single host allocation. The excessive-length rejection still holds (test value > 256MB). 166 verify-core tests pass; the varint Kani proof is parameterized on the constant. Tighter input-bounded read noted for the embedded profile (REQ-15). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
avrabe
added a commit
that referenced
this pull request
Aug 5, 2026
* release: v0.9.4 — unbreak the release + real #164 fix (sign large wasip2 components) Ships the release-integrity fixes now on main: - #213: MAX_SLICE_LEN 16MB -> 256MB so wsc-cli.wasm (large embedded core module) signs+verifies — the real #164 bug (rivet REQ-19 / DD-10). - #212: bare @wsc_deps//:ureq Bazel alias (dep drift unbroke the build). - #214: witness MC/DC baseline 12->17 (std/dep churn, documented; #128). - accumulated dep/action bumps since v0.9.3. Verified: release run build->sign->verify->publish green; 609 lib tests pass; Kani varint proof holds; witness gate green (17==17). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * release: sync Bazel version strings 0.9.0 -> 0.9.4 (clean-room finding) The Bazel-built CLI injects CARGO_PKG_VERSION from src/cli/BUILD.bazel's VERSION const, and MODULE.bazel carries the module version — both were stale at 0.9.0 despite 'keep in sync with workspace.version' comments. The release builds wsc-cli.wasm via Bazel, so the shipped CLI would have reported 0.9.0. Caught by the pre-tag clean-room verification. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * release: bump crossbeam-epoch 0.9.20 + wasmtime patch (RUSTSEC-2026-0204/0222/0223) Cargo Audit flagged 3 advisories in deps accumulated since v0.9.3: - crossbeam-epoch RUSTSEC-2026-0204 (invalid ptr deref) -> 0.9.20 - wasmtime RUSTSEC-2026-0222 (type-index mixup) + RUSTSEC-2026-0223 (bulk-op preemption) -> patched (wasmtime is optional/runtime-only, not in shipped binaries, but audit scans the whole lock). cargo audit clean (exit 0). Lockfile-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The real #164 bug — and the actual cause of the failing release. My earlier close (#192) was premature; #192 only surfaced it (hard-requirement → loud failure instead of silent drop).
What happened
2026-08-05 release (after the ureq/#212 build fix): reached the sign step.
wsc-component.wasm(3.96MB) signed fine;wsc-cli.wasm→ "Parse error".Root cause
Section::deserializerejects any section payload >MAX_SLICE_LEN(16MB). A wasm component's embedded core-module section for a fullwasm32-wasip2CLI exceeds 16MB. Reproduced with a synthetic >16MB-section module (ParseError → signs+verifies at 256MB).Fix
Raise
MAX_SLICE_LEN16MB → 256MB. Generous for any realistic component, still bounds a single host allocation. Excessive-length rejection still holds (test value > 256MB). 166 verify-core tests pass; big-section + small-module sign/verify round-trips confirmed locally. Tighter input-bounded read noted as embedded-profile (REQ-15) follow-up.Closes #164 (for real this time). Unblocks the release sign step + agora#3.
🤖 Generated with Claude Code