Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion sdk/rust/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -14,5 +14,5 @@ ureq = "2"
serde_json = "1"
base64 = "0.22" # 0.5.1 β€” wallet_hook(privy) needs Basic auth encoding
urlencoding = "2" # 0.5.1 β€” wallet_hook(privy) URL-encodes the wallet_id path segment
p256 = { version = "0.13", features = ["pkcs8", "ecdsa"] } # 0.6.2 β€” CDP-JWT (ES256) signing
p256 = { version = "0.14", features = ["pkcs8", "ecdsa"] } # 0.6.2 β€” CDP-JWT (ES256) signing

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟑 Release notes not updated for the Rust client's dependency upgrade

The published Rust client's cryptography dependency is moved to a new major version (p256 = "0.14" at sdk/rust/Cargo.toml:17) without any matching entry being added to the project's unreleased release notes, so users get a change that is never announced.
Impact: People using the Rust client won't see any record of the upgrade when it ships.

Repository rule: CHANGELOG Unreleased must be updated for user-facing changes

AGENTS.md requires: "Conventional Commit titles; update CHANGELOG.md (Unreleased) for user-facing changes." The Unreleased section of CHANGELOG.md:7 is empty and this PR touches only sdk/rust/Cargo.toml. A major bump of a dependency of the published wave-dispatch crate affects downstream dependency resolution and is therefore user-facing.

Prompt for agents
AGENTS.md mandates updating CHANGELOG.md's Unreleased section for user-facing changes. This PR bumps p256 from 0.13 to 0.14 in sdk/rust/Cargo.toml (a dependency of the published wave-dispatch crate) but leaves the Unreleased section of CHANGELOG.md empty. Add a Changed/Dependencies entry noting the p256 major upgrade for the Rust SDK.
Open in Devin Review

Was this helpful? React with πŸ‘ or πŸ‘Ž to provide feedback.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ” ECDSA signing API surface should be re-verified against the new major

The signer at sdk/rust/src/lib.rs:15-41 relies on p256::pkcs8::DecodePrivateKey, signature::Signer, and Signature::to_bytes() returning raw r||s (IEEE P-1363) for JWS ES256. The p256 0.14 line rides new ecdsa/signature/pkcs8 majors; if to_bytes() semantics or the trait re-exports changed, the produced CDP-JWT could be malformed or fail to parse PKCS8 PEM keys at runtime. Please confirm against the p256 0.14 changelog and, ideally, add a signing round-trip test.

Open in Devin Review

Was this helpful? React with πŸ‘ or πŸ‘Ž to provide feedback.

@devin-ai-integration devin-ai-integration Bot Aug 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ”΄ Rust SDK's random nonce source disappears with the upgraded crypto library, breaking the client build

The upgraded elliptic-curve stack (p256 = "0.14" at sdk/rust/Cargo.toml:17) no longer pulls in the old random-number package the SDK relies on for its one-time signing value, so the client no longer builds and its signing feature is unusable.
Impact: Anyone depending on the Rust client gets a broken build, and the paid-request signing flow stops working.

Lost feature unification of rand_core's `getrandom`

sdk/rust/src/lib.rs:22 does use rand_core::{OsRng, RngCore};, but OsRng in rand_core 0.6 only exists when the crate's getrandom feature is enabled. sdk/rust/Cargo.toml:18 declares rand_core = "0.6" with no features, so today it compiles only because p256 0.13 β†’ elliptic-curve 0.13 depends on rand_core ^0.6.4 and its std/getrandom feature chain enables rand_core/getrandom via feature unification.

elliptic-curve 0.14 (what p256 0.14.0 depends on, verified from the crates.io index) switched to rand_core ^0.10, so nothing enables rand_core 0.6/getrandom anymore and rand_core::OsRng becomes unresolvable. Additionally p256 0.14.0 declares rust-version = 1.85 and moves to ecdsa 0.17, so the Signature/SigningKey/p256::pkcs8 usage in sdk/rust/src/lib.rs:15-36 should be re-verified against the new API before merging.

Open in Devin Review

Was this helpful? React with πŸ‘ or πŸ‘Ž to provide feedback.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ” No lockfile or cargo job means Rust SDK dependency bumps are unverified

The repo has no Cargo.lock for sdk/rust and .github/workflows contains no cargo build/test/clippy job, so a breaking dependency bump like this one is merged without any compilation evidence. Worth verifying locally (cargo build -p wave-dispatch) before merge, and adding a minimal cargo check job so future Renovate PRs against the Rust SDK are gated.

Open in Devin Review

Was this helpful? React with πŸ‘ or πŸ‘Ž to provide feedback.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ” MSRV bump to 1.85 is not declared in the crate manifest

p256 0.14.0 declares rust-version = 1.85 (verified via the crates.io index), while sdk/rust/Cargo.toml has no rust-version field. Downstream consumers on older toolchains will hit an opaque failure rather than a clear MSRV error. Consider adding rust-version = "1.85" to sdk/rust/Cargo.toml and confirming CI's toolchain (no cargo job exists in .github/workflows, so this bump appears to be entirely unverified by CI).

Open in Devin Review

Was this helpful? React with πŸ‘ or πŸ‘Ž to provide feedback.

rand_core = "0.6" # 0.6.2 β€” nonce randomness for CDP-JWT
Comment on lines +17 to 18

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ” rand_core stays at 0.6 while p256 moves to a new major line

sdk/rust/src/lib.rs:22-23 pulls OsRng directly from rand_core = "0.6" (declared at sdk/rust/Cargo.toml:18) without enabling the getrandom feature; with p256 0.13 that feature was likely being unified in via the elliptic-curve/ecdsa dependency tree. p256 0.14 (RustCrypto 0.14 line) moves to the newer rand_core, so that unification disappears and the two RNG stacks are now independent β€” worth verifying the SDK still builds and that nonce generation is actually random. There is no cargo build/test workflow in .github/workflows, so nothing in CI will catch a break here.

Open in Devin Review

Was this helpful? React with πŸ‘ or πŸ‘Ž to provide feedback.

Loading