Skip to content

chore(deps): bump base64 from 0.22.1 to 0.23.1 - #2055

Open
dependabot[bot] wants to merge 1 commit into
developfrom
dependabot/cargo/develop/base64-0.23.1
Open

chore(deps): bump base64 from 0.22.1 to 0.23.1#2055
dependabot[bot] wants to merge 1 commit into
developfrom
dependabot/cargo/develop/base64-0.23.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 7, 2026

Copy link
Copy Markdown
Contributor

Bumps base64 from 0.22.1 to 0.23.1.

Changelog

Sourced from base64's changelog.

0.23.1

  • Make the tests build again on non-SIMD architectures

0.23.0

  • Added more consts for preconfigured configs and engines
  • Make DecodeError::InvalidLastSymbol more clear by including the decoded value
  • Added SIMD-accelerated engines behind the default-on simd-unsafe feature: Simd picks the best instruction set at runtime (AVX2 on x86_64, NEON on aarch64) and falls back to the scalar GeneralPurpose engine, while Avx2 and Neon target one instruction set with no runtime detection and work in no_std. The engines support the standard and URL-safe alphabets.
  • Update MSRV to 1.71.0
  • Add support for custom padding symbols
Commits
  • 069bf70 v0.23.1
  • 6ab1fb0 Merge pull request #310 from musicinmybrain/test-on-non-simd-arches
  • 7cffce6 Fix testing on architectures without unsafe SIMD support
  • e34f9a0 Merge pull request #308 from atouchet/com
  • e9240c9 Remove outdated comment
  • 9e9220a v0.23.0
  • 870326e Merge pull request #306 from marshallpierce/mp/trailing-bits-docs
  • fbec5f1 Document no trailing trailing bits
  • 0a23549 Merge pull request #305 from marshallpierce/mp/edition-2021
  • f10b7e2 Update deps & edition
  • Additional commits viewable in compare view

@dependabot dependabot Bot added Build | Project System Compiling and Packaging Dependencies Related to Dependencies labels Aug 7, 2026
@codecov

codecov Bot commented Aug 7, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.96%. Comparing base (e538927) to head (fb96b30).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #2055   +/-   ##
========================================
  Coverage    84.95%   84.96%           
========================================
  Files          351      351           
  Lines        30208    30208           
  Branches     30208    30208           
========================================
+ Hits         25664    25666    +2     
  Misses        4174     4174           
+ Partials       370      368    -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@da2ce7

da2ce7 commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

@dependabot rebase

@dependabot dependabot Bot changed the title chore(deps): bump base64 from 0.22.1 to 0.23.1 build(deps): bump base64 from 0.22.1 to 0.23.1 Sep 10, 2026
@dependabot
dependabot Bot force-pushed the dependabot/cargo/develop/base64-0.23.1 branch from 4e8fb4c to 202bcc3 Compare September 10, 2026 09:25

@da2ce7 da2ce7 left a comment

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.

Reviewed at 202bcc3f3ae36f9aaccbefd1048bdf6f991615bb.

Verified on a detached worktree at this exact head (rebased onto develop 89d45145, 0 behind), toolchain rustc 1.100.0-nightly (a69a63265 2026-09-03).

Diff. Cargo.toml moves the root package's base64 = "0.22.1" to "0.23.1"; Cargo.lock adds the new node and disambiguates the ten existing edges to 0.22.1. Nothing else moves.

API compatibility. The workspace has exactly one first-party consumer, src/console/ci/qbittorrent_e2e/qbittorrent/config_builder.rs, which uses base64::Engine, engine::general_purpose::STANDARD and Engine::encode. Comparing the two crate sources directly: pub const STANDARD: GeneralPurpose = GeneralPurpose::new(&alphabet::STANDARD, PAD) and fn encode<T: AsRef<[u8]>>(&self, input: T) -> String are unchanged across the majors. The 0.23 breaking items are DecodeError::InvalidLastSymbol now carrying the decoded value (decode path, unused here) and MSRV 1.71.0 (the workspace pins rust-version = "1.88").

Gates at this head, --workspace --all-targets --all-features:

gate exit wall
cargo check 0 10.4s
cargo clippy … -- -D warnings 0 12.0s
cargo test 0 155.6s — 57 suites, 2603 passed, 0 failed
cargo machete --with-metadata 0 7.5s
cargo deny check bans 0 1.4s
linter all 0 27.7s
contrib/dev-tools/git/hooks/pre-commit.sh 0 53.4s — all 6 steps pass
cargo test --doc --workspace 0 6.2s — 30 passed

The last two are included because --all-targets skips doctests, so the gate set above does not on its own cover what the hook covers.

Suggestion — simd-unsafe and forbid(unsafe_code). 0.23 adds a default-on simd-unsafe feature, and that changes the crate's own lint posture. 0.22.1 carried an unconditional #![forbid(unsafe_code)] at src/lib.rs:233; 0.23.1 carries

#![cfg_attr(not(feature = "simd-unsafe"), forbid(unsafe_code))]
#![cfg_attr(feature = "simd-unsafe", deny(unsafe_code))]

so under the default features this PR selects, base64 compiles unsafe, confined to its SIMD engine module. No repo lint fails because of it: clippy -D warnings and linter all are green with the feature active, and [workspace.lints.rust] unsafe_code reaches only first-party code.

A follow-up worth considering, separately from this bump:

base64 = { version = "0.23.1", default-features = false, features = ["std"] }

std implies alloc, which is all Engine::encode needs, and it restores the unconditional forbid(unsafe_code). The single use here encodes a short salt and digest while building a qBittorrent configuration for the E2E console tool, so the SIMD engines buy nothing measurable in exchange for the dropped guarantee. Not a blocker — it is an independently reviewable one-line change, and the bump is sound without it.

Nit — duplicate major. After this PR the graph carries base64 0.23.1 for torrust-tracker alone and base64 0.22.1 for ten transitive crates (bollard, bollard-stubs, docker_credential, hyper-util, reqwest, serde_with, sqlx-core, sqlx-mysql, sqlx-postgres, tonic). cargo deny check bans reports warning[duplicate]: found 2 duplicate entries for crate 'base64' and still exits ok, matching deny.toml's deliberate multiple-versions = "warn" and the pre-existing duplicate backlog recorded in its comment. Something to count into that backlog, not to act on here.

Checklist items a manifest and lockfile change cannot exercise are non-applicable: no new functionality so no new tests, no public API added so no doc comments, no user-facing behaviour change so no docs update, no new terms for project-words.txt. Title is Conventional Commits, base branch is develop, and the description carries the upstream changelog.

CI at this head. Every workflow run is green except one: Testing (push) run 34460558635, whose sole failing job is Docker E2E. Green: Testing (pull_request) 34460562997, OS Compatibility 34460562953 / 34460558644, Database Compatibility 34460558638, Database Benchmarking 34460558677, Container 34460562891, Generate Coverage Report (PR) 34460562912, Docs Lint 34460562933 / 34460558653, Copilot Setup Steps 34460558617.

That Docker E2E red is #2179's defect, not this bump's. The job log fails at cargo run --bin e2e_tests_runner … with error: no bin target named 'e2e_tests_runner' in default-run packages / help: available bin in 'torrust-tracker-e2e-tools' package, i.e. the missing -p flag described in #2179 (specification in #2194). It reproduces identically on the other two dependabot heads currently open and cannot be affected by a dependency version, since it fails before any test runs. The pull_request run's Docker E2E is skipped by design, because container.yaml covers that event.

@da2ce7

da2ce7 commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

ACK 202bcc3 — base64 0.23.1: sole consumer's Engine/STANDARD/encode surface unchanged across the major, and check, clippy -D warnings, test (2603 passed), machete, deny bans, linter all, doctests and the pre-commit hook all green at this head.

@da2ce7

da2ce7 commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

@dependabot rebase

@dependabot
dependabot Bot force-pushed the dependabot/cargo/develop/base64-0.23.1 branch from 202bcc3 to 16bf7fa Compare September 10, 2026 15:51
da2ce7
da2ce7 previously approved these changes Sep 10, 2026

@da2ce7 da2ce7 left a comment

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.

Re-reviewed at 16bf7faf0368e42d9cb7ee73c619a5d7930e39a0 on 2026-09-10, after the rebase onto develop 65a077b5 (merge-base is 65a077b5, 0 behind).

Verified on a detached worktree at this exact head, toolchain rustc 1.100.0-nightly (a69a63265 2026-09-03), cargo 1.100.0-nightly (b2e9d5f9d 2026-09-02).

Rebase. The head moved from 202bcc3f3ae36f9aaccbefd1048bdf6f991615bb to 16bf7faf0368e42d9cb7ee73c619a5d7930e39a0 when the branch was rebased from develop 89d45145 onto 65a077b5. The patch itself did not change: git diff 89d45145 202bcc3f and git diff 65a077b5 16bf7faf produce byte-identical output (3922 bytes, 129 lines), so the diff-of-diffs is empty and this is the same change re-parented. Both old and new head are single commits whose only parent is the respective base.

What develop gained in between is #2188 and #2189 — six documentation files plus tests/AGENTS.md and tests/common/workspace.rs, which drops the environment-variable guard from the integration-test fixture in favour of an explicit config path. Nothing in that delta mentions base64, syn or rstest, and it touches no Cargo.toml and no Cargo.lock, so it cannot interact with this bump. The gates below were nonetheless re-run in full at the new head rather than carried over.

Diff. Two files, 18 insertions / 12 deletions. Cargo.toml moves the root torrust-tracker package's base64 = "0.22.1" to "0.23.1" with no default-features or features key, so the default feature set applies. Cargo.lock adds the 0.23.1 node and disambiguates the ten existing edges to 0.22.1; no other package version moves.

API, re-derived from the vendored sources at the locked versions. The one first-party consumer, src/console/ci/qbittorrent_e2e/qbittorrent/config_builder.rs, uses exactly three items: base64::Engine, base64::engine::general_purpose::STANDARD and Engine::encode. All three are unchanged across the major. STANDARD is pub const STANDARD: GeneralPurpose = GeneralPurpose::new(&alphabet::STANDARD, PAD); at base64-0.23.1/src/engine/general_purpose/mod.rs:436 and character-for-character the same at base64-0.22.1/src/engine/general_purpose/mod.rs:332. Engine::encode is fn encode<T: AsRef<[u8]>>(&self, input: T) -> String at base64-0.23.1/src/engine/mod.rs:148, the same signature as at base64-0.22.1/src/engine/mod.rs:115. The 0.23 breaking items sit on the decode path, which this repository never touches.

Suggestion, unchanged from the previous round. 0.23's default = ["std", "simd-unsafe"] replaces the crate's unconditional #![forbid(unsafe_code)] (base64-0.22.1/src/lib.rs:233) with a pair of conditional attributes (base64-0.23.1/src/lib.rs:284-285):

#![cfg_attr(not(feature = "simd-unsafe"), forbid(unsafe_code))]
#![cfg_attr(feature = "simd-unsafe", deny(unsafe_code))]

Taking base64 = { version = "0.23.1", default-features = false, features = ["std"] } would keep the forbid posture; std implies alloc, which is all Engine::encode needs, and the single call site encodes a short salt and digest while writing a qBittorrent configuration file, so the SIMD engines buy nothing measurable here. Not a blocker: clippy -D warnings and linter all are green with the feature active, and the crate confines its unsafe to the SIMD engine module.

Nit. The lockfile now carries two base64 majors: 0.23.1 with exactly one dependent, torrust-tracker, and 0.22.1 with ten transitive ones — bollard, bollard-stubs, docker_credential, hyper-util, reqwest, serde_with, sqlx-core, sqlx-mysql, sqlx-postgres and tonic. cargo deny check bans reports it as warning[duplicate]: found 2 duplicate entries for crate 'base64' and still exits ok, alongside the pre-existing duplicate warnings for getrandom, rand, syn, thiserror and others that deny.toml's multiple-versions = "warn" already accommodates. The duplicate resolves itself when those transitive crates move.

The MSRV rise, 1.48.0 to 1.71.0, is absorbed by the workspace's rust-version = "1.88".

Gates at this head, all on the server, one shared target directory, the three PRs serialized under a lock:

gate exit wall
cargo check --workspace --all-targets --all-features 0 1.4s
cargo clippy --workspace --all-targets --all-features -- -D warnings 0 1.2s
cargo test --workspace --all-targets --all-features 0 132.8s — 57 suites, 2603 passed, 0 failed, 0 ignored
cargo test --doc --workspace 0 6.3s — 30 passed, 0 failed, 2 ignored
cargo machete --with-metadata 0 7.4s — no unused dependencies
cargo deny check bans 0 1.5s — bans ok
linter all 0 18.4s
contrib/dev-tools/git/hooks/pre-commit.sh 0 33.6s — all 6 steps pass

The suite and case totals are identical across all three rebased heads and identical to the previous round, which is the empirical statement that this bump changes no test outcome.

CI at this head.

workflow (event) run conclusion
Testing (pull_request) 34498392051 success
Testing (pull_request) 34498392090 success
Testing (push) 34498386985 failureDocker E2E only
Container (pull_request) 34498392061 success
Container (pull_request) 34498392064 success
OS Compatibility (pull_request) 34498391993 success
OS Compatibility (pull_request) 34498392036 success
OS Compatibility (push) 34498387072 success
Generate Coverage Report (PR) 34498392052 success
Generate Coverage Report (PR) 34498392086 success
Docs Lint (pull_request) 34498392019 success
Docs Lint (pull_request) 34498392060 success
Docs Lint (push) 34498386936 success

That one red is #2179, not this bump. In each failing run the only failing job is Docker E2E and within it the only failing step is Run E2E Tests; the preceding Build Tracker Image step succeeds and the three qBittorrent steps are skipped as downstream of the failure. The step runs cargo run --bin e2e_tests_runner -- … and cargo answers error: no bin target named 'e2e_tests_runner' in default-run packages, with its own help line naming the owning package: available bin in 'torrust-tracker-e2e-tools' package. That is the missing -p flag #2179 describes, it fails before any test executes, and it reproduces identically on all three rebased dependabot heads. The Docker E2E job is skipped on every pull_request run here because the job's if: guard excludes pull requests whose base is develop or main.

Everything else at this head is green: Unit (nightly), Unit (stable) and Layer Boundary Bans pass in both the push and the pull_request Testing runs.

@da2ce7

da2ce7 commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

ACK 16bf7fa — base64 0.23.1: patch byte-identical to the previously ACKed head, the sole consumer's Engine/STANDARD/encode surface is unchanged across the major, and all eight gates plus every CI job other than #2179's Docker E2E are green at this head.

@da2ce7

da2ce7 commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

@dependabot rebase

Bumps [base64](https://github.com/marshallpierce/rust-base64) from 0.22.1 to 0.23.1.
- [Changelog](https://github.com/marshallpierce/rust-base64/blob/master/RELEASE-NOTES.md)
- [Commits](marshallpierce/rust-base64@v0.22.1...v0.23.1)

---
updated-dependencies:
- dependency-name: base64
  dependency-version: 0.23.1
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot changed the title build(deps): bump base64 from 0.22.1 to 0.23.1 chore(deps): bump base64 from 0.22.1 to 0.23.1 Sep 11, 2026
@dependabot
dependabot Bot force-pushed the dependabot/cargo/develop/base64-0.23.1 branch from 16bf7fa to fb96b30 Compare September 11, 2026 16:49

@da2ce7 da2ce7 left a comment

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.

Re-reviewed at fb96b30818e9afef9d95e3df0b2a3d777583ff46 (round r3), after the rebase onto develop e53892791af6f497ce4c35bce6bc7a3c55c97ee2, which now carries the all-dependencies maintenance update. Verified on a detached worktree at this exact head, toolchain rustc 1.100.0-nightly (a69a63265 2026-09-03), cargo 1.100.0-nightly (b2e9d5f9d 2026-09-02).

Verdict: approve. No blockers.

What moved since the previous round

The head went from 16bf7faf to fb96b308, and the change got materially smaller. The manifest hunk is byte-identical — root Cargo.toml:76, base64 = "0.22.1" to "0.23.1", still with no default-features or features key — but the lock hunk collapsed from 28 changed lines to one. At the previous round this branch had to add the base64 0.23.1 node itself and disambiguate ten existing base64 edges; develop now already carries the 0.23.1 node and the disambiguated edges, so all that remains is retargeting the torrust-tracker package's own edge.

That is not merely cosmetic, and it changes the analysis in a way worth stating precisely.

Reverse dependencies, recomputed at this head

crate on develop e5389279 at this head
base64 0.22.1 8 direct dependents (bollard, bollard-stubs, docker_credential, hyper-util, sqlx-core, sqlx-mysql, sqlx-postgres, tonic) plus torrust-tracker the same 8 transitive crates; torrust-tracker is gone
base64 0.23.1 1 direct dependent: reqwest v0.13.5 reqwest v0.13.5 and torrust-tracker

So base64 0.23.1 is already compiled on develop, pulled in by reqwest 0.13.5, which this repository depends on directly and through six workspace packages. This PR adds no crate and no crate version to the build; it re-points the one first-party edge at a version already present, and removes torrust-tracker from the 0.22.1 fan-in. The 0.22.1 line stays for the eight transitive crates above and resolves as they migrate.

The simd-unsafe question, re-derived — and a correction to carry into the follow-up

Confirmed again from the vendored sources rather than the changelog. base64 0.23.1 declares default = ["std", "simd-unsafe"] (Cargo.toml:42-48), and src/lib.rs:284-285 replaces 0.22.1's unconditional #![forbid(unsafe_code)] (base64-0.22.1/src/lib.rs:233) with:

#![cfg_attr(not(feature = "simd-unsafe"), forbid(unsafe_code))]
#![cfg_attr(feature = "simd-unsafe", deny(unsafe_code))]

The consumer is unchanged and still trivial: src/console/ci/qbittorrent_e2e/qbittorrent/config_builder.rs imports base64::Engine and base64::engine::general_purpose::STANDARD (lines 6-7) and makes two Engine::encode calls on a short salt and digest while writing a qBittorrent configuration file (lines 126-127). STANDARD is a GeneralPurpose engine — the scalar one; the SIMD engines are separate types (Simd, Avx2, Neon) that nothing here names.

The new fact, and the reason this is not a blocker at all: simd-unsafe is already enabled on develop, before this PR. cargo tree -e features -i base64@0.23.1 at e5389279 resolves {alloc, default, simd-unsafe, std}, because reqwest 0.13.5 declares base64 = "0.23" with no default-features = false. The relaxed deny(unsafe_code) posture is therefore the status quo of the base branch; this bump does not introduce it and does not change it.

That has a consequence for the planned feature-pinning follow-up, which is worth flagging before it is written: setting default-features = false, features = ["std"] on this repository's own base64 dependency will not restore forbid(unsafe_code). Cargo unifies features across the whole graph, and reqwest will keep enabling base64/default. Pinning the direct dependency would make the repository's own intent explicit — a reasonable thing to want — but it would not remove the SIMD unsafe from the build, and the follow-up should say so rather than claim an unsafe-posture improvement it cannot deliver. Removing simd-unsafe from the build would require reqwest to stop enabling it.

base64 0.23.1 declares rust-version = "1.71.0", which the workspace rust-version = "1.88" absorbs; the changelog's "Update MSRV to 1.71.0" checks out against the crate manifest. The 0.23 breaking items sit on the decode path and in DecodeError::InvalidLastSymbol, which this repository never touches.

Nit

cargo deny check bans reports warning[duplicate]: found 2 duplicate entries for crate 'base64'. That duplicate already exists on develop — both versions are in the base lock — so this PR neither creates nor removes it, and deny.toml's multiple-versions = "warn" accommodates it alongside the pre-existing duplicates for getrandom, rand, syn, thiserror and others. bans ok.

Gates

Server lane, detached worktree at fb96b308, one shared target directory under a lock; wait is time spent blocked on that lock, run is the command itself.

gate exit wait run result
cargo tree --workspace --locked --depth 0 0 110.1s 0.3s lock consistent with the manifests
cargo check --workspace --all-targets 0 21.5s 3.3s
cargo clippy --workspace --all-targets -- -D warnings 0 1.4s 4.2s
cargo test --workspace 0 164.0s 147.0s 78 suites, 2631 passed, 0 failed, 2 ignored
cargo test --doc --workspace 0 15.4s 6.1s 24 suites, 30 passed, 0 failed, 2 ignored
cargo deny check bans 0 15.6s 1.4s bans ok
linter all 0 38.4s 21.2s all linters passed
contrib/dev-tools/git/hooks/pre-commit.sh --format=json 0 33.0s 33.9s all 6 steps pass

The check log shows Checking torrust-tracker v3.0.0-develop — the root crate really was recompiled against base64 0.23.1 rather than served from cache. The workspace test totals are identical to those measured at develop e5389279 and at the sibling syn head, which is the empirical statement that this bump changes no test outcome.

One note on method: a bare cargo machete exits 1 here with two findings — torrust-tracker in packages/e2e-tools and torrust-tracker-client-lib in packages/test-helpers. Those reproduce byte-identically on develop e5389279, so they are pre-existing and unrelated to this PR, and the repository's own gate is cargo machete --with-metadata (pre-commit step 2), which passes in 8s.

CI at this head

All eight runs at fb96b308 reached a terminal state (triggered 16:49Z, last one completed by 17:40Z).

workflow (event) run conclusion
Testing (pull_request) 34624178419 success
Container (pull_request) 34624178345 success
OS Compatibility (pull_request) 34624178359 success
Generate Coverage Report (PR) 34624178440 success
Docs Lint (pull_request) 34624178527 success
Docs Lint (push) 34624175674 success
OS Compatibility (push) 34624175821 success
Testing (push) 34624175575 failureDocker E2E only

That single red is #2179, not this bump, and it fails in exactly the same way as at the sibling syn head. In run 34624175575 the jobs Unit (stable), Unit (nightly) and Layer Boundary Bans all pass; only Docker E2E fails, and within it only step 9 Run E2E Tests, after step 8 Build Tracker Image succeeded. The step runs cargo run --bin e2e_tests_runner -- … (.github/workflows/testing.yaml:185) and cargo answers:

error: no bin target named `e2e_tests_runner` in default-run packages
help: available bin in `torrust-tracker-e2e-tools` package:
    e2e_tests_runner

Cargo's own help line names the owning package, which is the missing -p that #2179 describes. It fails at target resolution before any code executes, so no dependency version can influence it. Steps 10-12 are skipped as downstream, and they carry the same missing--p shape at lines 189/193/197.

The corresponding Testing (pull_request) run is green with Docker E2E skipped: the job's if: guard excludes pull requests whose base is develop or main, and also pushes to develop/main/releases/*. That is why the defect never shows on develop and surfaces only on feature-branch pushes like this one.

@da2ce7

da2ce7 commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

ACK fb96b30 — one-line move of the root crate onto the base64 0.23.1 already resolved in develop via reqwest, with the two Engine::encode call sites unaffected, all workspace gates green, and the only red CI job being the pre-existing #2179 Docker E2E target-resolution defect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Build | Project System Compiling and Packaging Dependencies Related to Dependencies

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant