chore(deps): bump base64 from 0.22.1 to 0.23.1 - #2055
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 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. 🚀 New features to boost your workflow:
|
036d6c3 to
4f02d68
Compare
4f02d68 to
4e8fb4c
Compare
|
@dependabot rebase |
4e8fb4c to
202bcc3
Compare
da2ce7
left a comment
There was a problem hiding this comment.
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.
|
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. |
|
@dependabot rebase |
202bcc3 to
16bf7fa
Compare
da2ce7
left a comment
There was a problem hiding this comment.
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 | failure — Docker 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.
|
@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>
16bf7fa to
fb96b30
Compare
da2ce7
left a comment
There was a problem hiding this comment.
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 | failure — Docker 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.
Bumps base64 from 0.22.1 to 0.23.1.
Changelog
Sourced from base64's changelog.
Commits
069bf70v0.23.16ab1fb0Merge pull request #310 from musicinmybrain/test-on-non-simd-arches7cffce6Fix testing on architectures without unsafe SIMD supporte34f9a0Merge pull request #308 from atouchet/come9240c9Remove outdated comment9e9220av0.23.0870326eMerge pull request #306 from marshallpierce/mp/trailing-bits-docsfbec5f1Document no trailing trailing bits0a23549Merge pull request #305 from marshallpierce/mp/edition-2021f10b7e2Update deps & edition