chore(deps): update rust crate p256 to 0.14

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
p256 (source)	dependencies	minor	0.13 → 0.14

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 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.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

---

Note

Update p256 dependency to v0.14 in the Rust SDK

Bumps the p256 crate version constraint from 0.13 to 0.14 in Cargo.toml. The pkcs8 and ecdsa features are unchanged.

^{Macroscope summarized 2767f56.}

[greptile-apps]

PR author is in the excluded authors list.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e6a1031

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

Devin Review found 3 potential issues.

[devin-ai-integration]

🟡 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.

[devin-ai-integration]

🔍 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.

[devin-ai-integration]

🔍 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.

[macroscopeapp]

Approvability

Verdict: 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 2767f56. Prior analysis still applies.

^{You can customize Macroscope's approvability policy. Learn more.}

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🔴 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.

[devin-ai-integration]

🔍 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.

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 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.