Skip to content

chore(deps): update rust crate base64 to 0.23 #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
renovate wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): update rust crate base64 to 0.23 #38

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ categories = ["api-bindings"]
[dependencies]
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

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@devin-ai-integration devin-ai-integration Bot Aug 14, 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.

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

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@yakimoto yakimoto Sep 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

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
rand_core = "0.6" # 0.6.2 — nonce randomness for CDP-JWT
Loading