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.
There was a problem hiding this comment.
Confirmed against the registry — this one is real, so I am leaving it open rather than resolving it.
$ curl -s https://crates.io/api/v1/crates/base64/0.23.0 | jq .version.features
{
"alloc": [],
"default": ["std", "simd-unsafe"],
"simd-unsafe": [],
"std": ["alloc"]
}
simd-unsafe is in default, and sdk/rust/Cargo.toml declares base64 = "0.23" with no default-features = false. So the feature is enabled, exactly as described.
What makes this worth acting on is that it is a silent change in posture: 0.22 had no such feature, so the bump expands the published crate unsafe surface without a single line of the diff saying so. Nobody reading -base64 = "0.22" / +base64 = "0.23" would see it.
The minimal fix keeps the two call sites working while restoring the 0.22 posture:
base64 = { version = "0.23", default-features = false, features = ["std"] }Both usages — URL_SAFE_NO_PAD.encode (sdk/rust/src/lib.rs:30) and STANDARD.encode (line 234) — are Engine::encode calls that need only std (which pulls alloc), so dropping simd-unsafe should not touch them.
I am deliberately not pushing that change, because I have no Rust toolchain here (command -v cargo -> not found) and I will not put an unverified dependency edit on a published crate. It needs someone who can actually run cargo build and cargo test on the SDK.
Related and worth fixing separately: nothing in CI compiles Rust at all — cargo appears in .github/workflows/ only inside a comment in license-truth.yml. That is why this PR and the other Rust bumps (rand_core, p256, ureq) all show green: no gate ever builds them. A cargo check --locked job over sdk/rust would give these bumps real signal.
21c09c8 to
7ecbdfa
Compare
|
Your free trial PR review limit of 300 PRs has been reached. Please upgrade your plan to continue using CodeAnt AI. |
7ecbdfa to
ce7f3b3
Compare
|
Your free trial PR review limit of 300 PRs has been reached. Please upgrade your plan to continue using CodeAnt AI. |
1 participant
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 becomes conflicted, 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.