chore(deps): update rust crate p256 to 0.14 - #32
Conversation
|
PR author is in the excluded authors list. |
|
e14fd38 to
e6a1031
Compare
e6a1031 to
b07b754
Compare
| 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 |
There was a problem hiding this comment.
🟡 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.
Was this helpful? React with 👍 or 👎 to provide feedback.
| p256 = { version = "0.14", features = ["pkcs8", "ecdsa"] } # 0.6.2 — CDP-JWT (ES256) signing | ||
| rand_core = "0.6" # 0.6.2 — nonce randomness for CDP-JWT |
There was a problem hiding this comment.
🔍 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.
Was this helpful? React with 👍 or 👎 to provide feedback.
| 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 |
There was a problem hiding this comment.
🔍 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.
Was this helpful? React with 👍 or 👎 to provide feedback.
ApprovabilityVerdict: Needs human review Unable to check for correctness in b07b754. This dependency update affects p256, a cryptographic library used for ES256/JWT signing. Security-related dependencies warrant review by the owning team (wave-av/streaming-team) even for minor version bumps. No code changes detected at You can customize Macroscope's approvability policy. Learn more. |
b07b754 to
1f8cd84
Compare
| 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 |
There was a problem hiding this comment.
🔴 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.
Was this helpful? React with 👍 or 👎 to provide feedback.
| 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 |
There was a problem hiding this comment.
🔍 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.
Was this helpful? React with 👍 or 👎 to provide feedback.
1f8cd84 to
2767f56
Compare
| 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 |
There was a problem hiding this comment.
🔍 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).
Was this helpful? React with 👍 or 👎 to provide feedback.
2767f56 to
1e990f3
Compare
This PR contains the following updates:
0.13→0.14Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.