chore(deps): update rust crate base64 to 0.23 - #38
Conversation
|
0f22a5c to
2f349ac
Compare
|
PR author is in the excluded authors list. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| ureq = "2" | ||
| serde_json = "1" | ||
| base64 = "0.22" # 0.5.1 — wallet_hook(privy) needs Basic auth encoding | ||
| base64 = "0.23" # 0.5.1 — wallet_hook(privy) needs Basic auth encoding |
There was a problem hiding this comment.
📝 Info: APIs used by the SDK are unaffected by the 0.22→0.23 bump; MSRV not pinned in-repo
Only two base64 usages exist in the Rust SDK — base64::engine::general_purpose::URL_SAFE_NO_PAD.encode (sdk/rust/src/lib.rs:30) and general_purpose::STANDARD.encode (sdk/rust/src/lib.rs:234) — both engine-API calls introduced in 0.21 and retained in 0.23; the 0.23 breaking notes concern DecodeError::InvalidLastSymbol and new consts/features, none of which are used (no decoding anywhere in the SDK). The new MSRV of 1.71.0 is also not a conflict: neither sdk/rust/Cargo.toml nor any workflow pins a rust-version/toolchain. Existing precedent in git history also shows dependency bumps not being recorded in CHANGELOG.md, so the missing Unreleased entry matches convention for non-user-facing chores.
Was this helpful? React with 👍 or 👎 to provide feedback.
ApprovabilityVerdict: Needs human review Unable to check for correctness in 2f349ac. Dependency update to base64 0.23 touches a file owned by wave-av/streaming-team (not owned by renovate bot). An open review comment raises valid concerns about verifying the new version exists and passes CI build. The designated code owners should verify this update. No code changes detected at You can customize Macroscope's approvability policy. Learn more. |
a649734 to
7492384
Compare
7492384 to
21c09c8
Compare
| ureq = "2" | ||
| serde_json = "1" | ||
| base64 = "0.22" # 0.5.1 — wallet_hook(privy) needs Basic auth encoding | ||
| base64 = "0.23" # 0.5.1 — wallet_hook(privy) needs Basic auth encoding |
There was a problem hiding this comment.
🔍 New default-on SIMD engine feature ships unsafe code into the SDK
Per the release notes quoted in the PR, base64 0.23 adds SIMD-accelerated engines behind a default-on simd-unsafe feature. The dependency here is declared without default-features = false, so the SDK will now pull in runtime-detected unsafe SIMD code paths for the two call sites (sdk/rust/src/lib.rs:30 for the CDP-JWT base64url encoding and sdk/rust/src/lib.rs:234 for the Privy Basic auth header). These call sites encode tiny payloads where SIMD gives no meaningful benefit, so for a crypto-adjacent client SDK it may be preferable to opt out of the unsafe feature (base64 = { version = "0.23", default-features = false, features = ["std"] }). Worth confirming whether the repo has a policy on transitive unsafe code.
Was this helpful? React with 👍 or 👎 to provide feedback.
This PR contains the following updates:
0.22→0.23Release Notes
marshallpierce/rust-base64 (base64)
v0.23.1Compare Source
v0.23.0Compare Source
simd-unsafefeature:Simdpicks the bestinstruction set at runtime (AVX2 on
x86_64, NEON onaarch64) and falls back to the scalarGeneralPurposeengine, whileAvx2andNeontarget one instruction set with no runtimedetection and work in
no_std. The engines support the standard and URL-safe alphabets.Configuration
📅 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.