workflow-rs v0.19.0 (maintenance release update) + Client SDK wRPC TLS features - #1065
Open
aspect wants to merge 16 commits into
Open
workflow-rs v0.19.0 (maintenance release update) + Client SDK wRPC TLS features#1065aspect wants to merge 16 commits into
aspect wants to merge 16 commits into
Conversation
- bump wasm pins: wasm-bindgen =0.2.126, js-sys =0.3.103, wasm-bindgen-futures =0.4.76, web-sys =0.3.103 - workflow-http features: rustls-tls-webpki-roots/macos-system-configuration -> rustls/system-proxy (reqwest 0.13 / workflow-http 0.19 rename) - wasm-bindgen 0.2.126 ABI: wrap ref_from_abi() u32 args with WasmPtr::from_usize() in crypto/addresses and consensus/core script_public_key - tungstenite 0.29: WebSocketConfig is non_exhaustive; use builder in wrpc server service.rs and proxy main.rs - js-sys 0.3.103: drop Eq derive on PrivateKeyArrayT wasm extern type Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A full `cargo` lock regeneration bumps `ahash` to a version that pulls getrandom 0.3 (via ark-crypto -> kaspa-txscript), which on wasm32 needs both the `wasm_js` feature and the `getrandom_backend="wasm_js"` cfg (the feature alone is insufficient). Previously this broke `./check` after any lock regen. - .cargo/config.toml: set `getrandom_backend="wasm_js"` for wasm32-unknown-unknown - kaspa-utils + kaspa-wasm: declare a `getrandom_03` (wasm_js) alias so the feature unifies across every wasm32 build root getrandom 0.2 is retained (required transitively by `ring` and `rand_core 0.6`, and selected via the manifest-based `js` feature, so it needs no cfg). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…2.126) The wasm-bindgen ecosystem is already at latest (wasm-bindgen 0.2.126, js-sys/ web-sys 0.3.103, wasm-bindgen-futures 0.4.76); align the wasm-bindgen-test floor so the manifest reflects the resolved version. Verified a full Cargo.lock regeneration (`rm Cargo.lock && ./check`) builds clean on native and wasm32, with node-sys gone and getrandom 0.3 handled by the wasm_js alias + backend cfg. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a section to the kaspa-wasm module rustdoc explaining that Rust crates depending on kaspa-wasm and building for wasm32-unknown-unknown must set `getrandom_backend="wasm_js"` in their own .cargo/config.toml — the cfg is required by transitive getrandom 0.3 and cannot be propagated from a library. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…g SDK)
reqwest 0.13 pulls the `aws-lc-rs` rustls provider (needs a C/cmake toolchain)
and only auto-selects that provider, while the wRPC/websocket stack uses `ring`.
Two providers make rustls 0.23 unable to auto-select one, panicking at runtime
("Could not automatically determine the process-level CryptoProvider").
Switch workflow-http to reqwest's `rustls-no-provider`, removing aws-lc-rs (and
its C build) so the only provider is the pure-Rust `ring`. Since reqwest
no-provider requires an installed provider, install `ring` from the SDK itself
(`ensure_crypto_provider`, called on Resolver/KaspaRpcClient construction) so
downstream Rust SDK consumers remain zero-config. The call is idempotent and a
no-op if a provider was already installed, and native-only (wasm uses host TLS).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ypto_provider public Add a "TLS crypto provider" section to the kaspa-wrpc-client crate docs explaining that it installs the pure-Rust `ring` provider automatically on first client/Resolver construction (zero-config), how to override it with another provider, and that wasm needs none. Expose `ensure_crypto_provider` so consumers can invoke it explicitly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- kaspa-wrpc-wasm: clarify that WASM/JS environments need no rustls crypto provider (the browser/Node.js host handles TLS), unlike the native client. - kaspa-rpc-core: note that native clients built on it (wrpc/grpc) require a rustls provider, which kaspa-wrpc-client installs automatically. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Switch all workflow-* dependencies from local ../workflow-rs paths to the published crates.io 0.19.0 release and regenerate Cargo.lock. TLS stack resolves to pure-Rust ring (no aws-lc-rs/C): wRPC via tokio-tungstenite rustls-tls-webpki-roots, HTTP via reqwest rustls-no-provider with the SDK installing ring at runtime. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two CI failures after the wasm-bindgen 0.2.100 -> 0.2.126 bump:
1. consensus-core wasm test no longer compiled: with 0.2.126 a #[wasm_bindgen]
struct's IntoWasmAbi::Abi is WasmPtr<WasmRefCell<T>> (not u32), so
`into_abi().into::<JsValue>()` no longer resolves. Use to_value(&spk) for the
serde round-trip, matching the sibling tests.
2. WASM32 SDK build failed in the wasm-bindgen CLI with `failed to find the
__wbindgen_externref_table_alloc function`. wasm-bindgen now manages JS object
handles through a reference-types externref table that --weak-refs relies on,
but the `-Ctarget-cpu=mvp` workaround (added for Rust 1.87, issue 141048)
strips reference-types. Keep the MVP baseline for maximum runtime
compatibility but add reference-types back on its own:
- workspace .cargo/config.toml wasm32 rustflags: -Ctarget-cpu=mvp
-Ctarget-feature=+reference-types (alongside the getrandom backend cfg),
as the single source of truth.
- drop the per-script `export RUSTFLAGS=-Ctarget-cpu=mvp` from
wasm/build-{release,node,web} (env RUSTFLAGS also clobbered the getrandom
cfg) and the now-shadowed wasm/.cargo/config.toml rustflags.
- wasm-opt profile.release: allow --enable-reference-types so the release
optimizer accepts the feature.
Verified: consensus-core wasm tests build; dev + release keygen and full
wasm32-sdk wasm-pack builds succeed with wasm-opt and --weak-refs.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The wRPC client TLS backend was forced workspace-wide via the
`workflow-rpc = { features = ["rustls-tls-webpki-roots"] }` dependency, so an
SDK consumer of kaspa-wrpc-client could not opt out of ring at compile time.
Move the selection into kaspa-wrpc-client's own features, forwarded to
workflow-rpc:
default = ["rustls-tls-webpki-roots"]
rustls-tls-webpki-roots = ["rustls-ring", "workflow-rpc/rustls-tls-webpki-roots"]
rustls-tls-native-roots = ["rustls-ring", "workflow-rpc/rustls-tls-native-roots"]
native-tls = ["workflow-rpc/native-tls"]
native-tls-vendored = ["workflow-rpc/native-tls-vendored"]
rustls-ring (internal) = ["dep:rustls"] # ring provider for the Resolver
A consumer can now `default-features = false` to drop ring entirely (then pick
another backend or install their own rustls CryptoProvider), while the default
preserves the previous zero-config ring behaviour. The workspace workflow-rpc
dep no longer selects a TLS backend (it stays default-features = false because
workflow-rpc itself defaults to native-tls).
rustls (and ring) is also made native-only via a
`cfg(not(target_arch = "wasm32"))` target table: on wasm32 the host terminates
TLS, so it must not be in the wasm graph. Previously rustls was an unconditional
dep that only compiled on wasm32 by accident (ring/getrandom `js` feature
unified in from other crates); now wasm32 is cleanly TLS-free and
ensure_crypto_provider() is a no-op there.
Verified: full ./check (native + wasm32) passes; ring present by default and
absent with default-features = false; wasm32 graph contains no rustls.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Same ABI break already fixed in consensus-core: with wasm-bindgen 0.2.126 a #[wasm_bindgen] struct's IntoWasmAbi::Abi is WasmPtr<WasmRefCell<T>> (not u32), so `into_abi().into::<JsValue>()` no longer resolves. Use to_value(&expected) for the serde round-trip and drop the now-unused IntoWasmAbi import. Also wire the wasm32 test suites into ./check. These #[cfg(target_arch = "wasm32")] #[wasm_bindgen_test] modules are only compiled by CI's test-wasm32 job, never by the native `--tests` clippy or the existing wasm32 clippy passes (which don't pass --tests for these crates) -- which is why this and the prior consensus-core break both reached CI. ./check now compiles --tests for wasm32 on kaspa-consensus-core, kaspa-addresses, kaspa-wallet-pskt, kaspa-txscript and kaspa-consensus-client (the CI test-wasm32 set). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
kaspanet#1064 deleted the Windows stub that defines risc0-zkvm-platform's `sys_alloc_aligned`, but the symbol is still undefined on the host: with `export-syscalls` off, risc0-zkvm-platform declares it `extern "C"` (provided by the zkVM runtime only). Unix .so/.dylib linking tolerates the undefined symbol (it is never called in verification-only use), but MSVC link.exe refuses to build a DLL with it -> LNK2019/LNK1120 for every cdylib transitively depending on kaspa-txscript (kaspa-wrpc-client, kaspa-wallet-pskt, ...), breaking Windows. Restore the prior workaround verbatim: a Windows-only build.rs (cc) compiling a C stub that defines sys_alloc_aligned via _aligned_malloc. The stub is #[cfg(windows)] only, so macOS/Linux builds are unaffected (build.rs main() is a no-op there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
biryukovmaxim
requested changes
Jun 27, 2026
Comment on lines
+13
to
+22
| //! ## TLS crypto provider (native clients) | ||
| //! | ||
| //! `kaspa-rpc-core` is transport-agnostic, but the native client implementations | ||
| //! built on it — [`kaspa_wrpc_client`](https://docs.rs/kaspa-wrpc-client) and | ||
| //! [`kaspa_grpc_client`](https://docs.rs/kaspa-grpc-client) — use `rustls`, which | ||
| //! since 0.23 requires a process-level crypto provider to be installed before the | ||
| //! first secure connection. `kaspa-wrpc-client` installs a pure-Rust `ring` | ||
| //! provider automatically (see its docs for how to override). WASM clients are | ||
| //! unaffected — the host handles TLS. | ||
| //! |
Collaborator
There was a problem hiding this comment.
comment feels redundant here
Collaborator
Author
There was a problem hiding this comment.
The goal is that a developer sees this when browsing docs in different crates. Want me to remove it? It can be a bit tricky to understand what may be needed if you haven't noticed these docs.
Collaborator
There was a problem hiding this comment.
Core apo/,trait docs should not reference anything that implements it, we don't know who will depend on it and how which makes maintenance if the doc tricky. I feel fine with all other places except this one
Comment on lines
+35
to
+41
| # getrandom 0.3 is pulled in transitively (ahash -> ark-crypto -> kaspa-txscript) | ||
| # and needs its `wasm_js` feature enabled on wasm32; the feature alone is no | ||
| # longer sufficient (it also needs the getrandom_backend cfg in .cargo/config.toml). | ||
| # kaspa-utils is in every wasm32 build root, so declaring the alias here unifies | ||
| # the feature across the whole workspace's wasm builds. | ||
| [target.'cfg(target_arch = "wasm32")'.dependencies] | ||
| getrandom_03 = { package = "getrandom", version = "0.3", features = ["wasm_js"] } |
Collaborator
There was a problem hiding this comment.
crate doesnt use getrandom at all, such dependency should not be added here.
Replace the Windows C-stub workaround (build.rs + cc + sys_alloc.c) with risc0-zkvm-platform's own `export-syscalls` feature. Without it the crate declares `sys_alloc_aligned` as `extern "C"` (provided only by the zkVM runtime), leaving it undefined on the host: Unix linkers tolerate the undefined symbol (it is never called in verification-only use) but MSVC link.exe rejects it when emitting a cdylib (LNK2019/LNK1120), breaking every Windows cdylib that transitively depends on kaspa-txscript (kaspa-wrpc-client, kaspa-wallet-pskt). `export-syscalls` makes risc0-zkvm-platform define the host stubs itself (sys_alloc_aligned -> `unimplemented!()` under not(target_os = "zkvm")), so the symbol is defined on every target. Verified: nm shows `T _sys_alloc_aligned` in the native rlib and the kaspa-wrpc-client cdylib; ./check (native + wasm32) passes. This drops the C toolchain / build.rs entirely and is platform-uniform rather than a Windows-only special case. 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
2 participants
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.
This PR upgrades
workflow-rstov0.19.0- workflow-rs/workflow-rs#18The new
workflow-rsversion provides the following key updates (TLDR):RUSTSECsecurity flags due to stale dependencies.WasmPtr).reqwestcrate).getrandomhas been updated tov0.3In Rusty Kaspa this PR bumps all WASM32-related dependencies and propagates new TLS features.