chore(deps): bump PulseEngine toolchains (meld 0.10, spar 0.10, synth 0.6, wsc 0.9) - #471
Merged
Merged
Conversation
Bumps four of the six PulseEngine tools to their latest releases. Each
version pin is updated everywhere it appears (JSON registry,
module-extension defaults, repository-rule defaults, MODULE.bazel
call sites) so the resolved version matches `latest_version` in the
registry.
* meld 0.1.0 -> 0.10.0 (canonical-ABI sweep + multi-memory warning)
* spar 0.9.3 -> 0.10.0 (mermaid emitter, EMV2 traversal, Lean 4 proofs)
* synth 0.3.1 -> 0.6.0 (cosign-signed sums, SBOM, SLSA provenance)
* wsc 0.7.0 -> 0.9.0 (TPM2 variant; registry entry only -- the
MODULE.bazel call site stays at 0.7.0 because
v0.9.0 dropped the wsc-cli.wasm asset our
wasmsign2_wrapper consumes, tracked upstream
as pulseengine/sigil#132)
Not bumped:
* loom pinned at 0.3.0 -- every release from v0.6.0 through v1.1.1
ships zero binary assets upstream
(pulseengine/loom#142)
* witness already at v0.22.0 (latest)
Validated locally: bazel build //examples/{spar,witness,synth}_example/...
green on darwin_arm64; spar generates WIT, synth compiles to Cortex-M
ELF, meld toolchain resolves.
A companion brief was filed on the five non-synth repos asking them to
adopt synth's release-artifact pattern (single SHA256SUMS.txt signed
keyless with cosign + SBOM + SLSA build provenance), to unify the
three different checksum/signing conventions currently in use across
the PulseEngine toolset.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This was referenced Jun 13, 2026
avrabe
added a commit
that referenced
this pull request
Jun 13, 2026
…ntry
Correcting the prior commit: I pointed the wasm_component platform at
wsc-component.wasm, which fetches but is a *component* that
`wasmtime run <wasm> keygen ...` cannot execute as a command module:
Error: failed to run main module `.../wasmsign2.wasm`
The wrapper runs the WASI *CLI* module. v0.7.0 ships both wsc-cli.wasm and
wsc-component.wasm; the pre-#471 registry used wsc-cli.wasm. Point 0.7.0 at
wsc-cli.wasm (sha a57139921f87e91282f22f788155177eadf2085e21a7f2f8ceb8d9fac1c761ef,
verified against the pulseengine/sigil sidecar).
Drop the 0.9.0 wasm_component entry: v0.9.0 ships only wsc-component.wasm (no
CLI module), so the current wrapper can't run it. Nothing fetches 0.9.0 (the
pin is 0.7.0); bumping past 0.7.0 needs the wrapper to handle the component
form (tracked in #498).
Verified by RUNNING it: `bazel build //examples/wasm_signing:example_keys`
fetches wsc-cli.wasm and successfully generates a key pair via the wrapper.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
avrabe
added a commit
that referenced
this pull request
Jun 13, 2026
…gning tree) (#499) * fix(checksums): restore wsc wasm_component platform (unbreaks wasm_signing) The wsc bump to per-OS binaries (#471) replaced wsc.json's universal wasm-component entry with per-platform binaries, dropping the `wasm_component` platform. But `@wasmsign2_cli_wasm` is a wasm_component_download(tool_name="wsc") that resolves only the `wasm`/`wasm_component` platform, so it failed to fetch: Error in fail: Tool 'wsc' version '0.7.0' not found in registry (tried platforms: wasm, wasm_component) This cascaded into analysis failures for //tools/wasmsign2_wrapper and the entire //examples/wasm_signing tree on every PR (the Test workflow runs on pull_request, not on main pushes, so it landed uncaught). Restore the `wasm_component` platform for 0.7.0 (pinned) and 0.9.0 (latest), pointing at the wsc-component.wasm asset. Checksums verified against the authoritative pulseengine/sigil release .sha256 sidecars: 0.7.0 15efa8033741c4613165ae49b002847df9afcc27af876778884c79aaea4d45b2 0.9.0 b40f70180a3c448b2f2fef21f42966c43a6cc11a7d5796db89de7abf969a1ba4 Verified locally: `bazel build //tools/wasmsign2_wrapper:wasmsign2_wrapper` now fetches wsc-component.wasm and builds successfully. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(checksums): use wsc-cli.wasm (runnable module), drop 0.9.0 wasm entry Correcting the prior commit: I pointed the wasm_component platform at wsc-component.wasm, which fetches but is a *component* that `wasmtime run <wasm> keygen ...` cannot execute as a command module: Error: failed to run main module `.../wasmsign2.wasm` The wrapper runs the WASI *CLI* module. v0.7.0 ships both wsc-cli.wasm and wsc-component.wasm; the pre-#471 registry used wsc-cli.wasm. Point 0.7.0 at wsc-cli.wasm (sha a57139921f87e91282f22f788155177eadf2085e21a7f2f8ceb8d9fac1c761ef, verified against the pulseengine/sigil sidecar). Drop the 0.9.0 wasm_component entry: v0.9.0 ships only wsc-component.wasm (no CLI module), so the current wrapper can't run it. Nothing fetches 0.9.0 (the pin is 0.7.0); bumping past 0.7.0 needs the wrapper to handle the component form (tracked in #498). Verified by RUNNING it: `bazel build //examples/wasm_signing:example_keys` fetches wsc-cli.wasm and successfully generates a key pair via the wrapper. 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.
Summary
Bumps four of the six PulseEngine pipeline tools to their latest releases:
Each version pin is updated everywhere it appears (JSON registry
latest_version, module-extension defaults inwasm/extensions.bzl, repository-rule defaults intoolchains/*.bzl, and theMODULE.bazelcall sites) so the resolved version actually matches the registry.Special handling: wsc
The wsc bump touches the registry (
checksums/tools/wsc.jsonnow lists v0.9.0) butMODULE.bazelstays pinned to v0.7.0 because the v0.9.0 release dropped thewsc-cli.wasmasset that ourtools/wasmsign2_wrapperconsumes. Filed upstream as pulseengine/sigil#132; the call site will move once the wasm artifact is reinstated or the wrapper switches to the native binary.Not bumped
Related: release artifact unification
While auditing the bumps I found three different SHA conventions and three different signing tiers across the six PulseEngine releases. Synth is the only one with the full stack (single signed
SHA256SUMS.txt+ SBOM + SLSA provenance). Filed brief on five repos asking them to adopt that pattern:Test plan
bazel build //examples/spar_example/... //examples/witness_example/... //examples/synth_example/...green on darwin_arm64building_control.aadl(7 components, working)ctx.download(would hard-fail on mismatch)🤖 Generated with Claude Code