Skip to content

fix(deps): clear the resolvable RUSTSEC advisories with a lockfile-only bump - #82

Open
bkataru wants to merge 1 commit into
mainfrom
fix/rustsec-2026-0285
Open

bkataru wants to merge 1 commit into
mainfrom
fix/rustsec-2026-0285

Conversation

@bkataru

@bkataru bkataru commented Oct 4, 2026 •

Copy link
Copy Markdown
Member

What

A lockfile-only bump that moves five crates to the newest version their declared semver
ranges already allow.

crate from to advisories that stop matching this copy
quinn-proto 0.11.15 0.11.18 RUSTSEC-2026-0338, -0339, -0340, -0341, -0342
rustls 0.23.39 0.23.46 RUSTSEC-2026-0285, -0346, -0348, -0349
rustls-webpki 0.103.13 0.103.16 RUSTSEC-2026-0382
webpki-root-certs 1.0.7 1.0.10 RUSTSEC-2026-0383
webpki-roots 1.0.7 1.0.10 RUSTSEC-2026-0381

aws-lc-rs and aws-lc-sys move with rustls 0.23.46; they are forced by that move, not
incidental drift.

Measured effect

cargo audit on the lockfile before and after:

before after rows cleared
with the repository's suppressions 14 3 11
with the suppressions removed 21 9 12

The audit gate still reports three findings

They are the legacy rustls 0.22.4 and rustls-webpki 0.102.8 copies: their dependency
requires rustls ^0.22, and that series has no release at or above the patched floor, so no
in-repo bump clears them. Both are reachable from the CLI, so they are reported rather than
suppressed - a suppression entry would hide a reachable advisory. Tracked in #153.

h2 0.3.27 (RUSTSEC-2026-0258) sits on the same line and stays suppressed for the same
reason.

RUSTSEC-2026-0285 leaves the suppression list

.cargo/audit.toml carried RUSTSEC-2026-0285 with the reason "externally blocked ... pins
rustls below the patched floor". The resolver moves that copy to 0.23.46 inside its own
range, so the reason did not describe what the resolver does. With the bump applied the
advisory matches no locked copy, so the entry is removed instead of being left to suppress
nothing.

Fixes #77
Fixes #143
Fixes #144
Fixes #145
Fixes #146
Fixes #147
Fixes #150

RUSTSEC-2026-0346 and RUSTSEC-2026-0349 are only partly addressed: their 0.23 copy is
fixed here, their legacy 0.22.4 copy is not, so #148, #149, #151 and #152 stay open.

@bkataru

bkataru commented Oct 4, 2026 •

Copy link
Copy Markdown
Member Author

Correction from the lane that opened #84: CI does run on main, and it was green. My "main receives no CI" claim was wrong — I read a truncated gh run list as complete and reported absence as fact.

Relevant here only because it changes one thing in my earlier comment on this PR: I said "main is unmeasured" and treated that as worse than red. It is neither — main was audited green on 2026-06-14 and has not changed since, so the baseline this PR diffs against is the baseline CI approved.

The red gates on #82 remain exactly as established: cargo audit (6 here, 7 on de893a9) and Check & Lint (4 pre-existing #[async_trait] lints), both failing on the pull_request trigger, both pre-existing relative to a Cargo.lock-only diff.

@bkataru

bkataru commented Oct 4, 2026 •

Copy link
Copy Markdown
Member Author

Subsumed by a single verified lockfile, posted on #83. This PR's CI cannot go green on its own: cargo audit fails on advisories outside its scope, and Check & Lint fails on clippy::double_must_use. Combining this bump with async-trait 0.1.92 + rustls 0.23.45 + quinn-proto 0.11.15 + crossbeam-epoch 0.9.20 + h2 0.4.16 + plist 1.10.1 takes the gate from 7 vulnerabilities to 1 with clippy exit 0 and 1826/1826 nextest green (lockfile sha 9dc234af6eba1997, lint result carries a planted-violation control at exit 101). No new PR opened — this needs review, not re-derivation. One caveat: h2 0.3.27 remains and no lockfile can clear it (see #81).

@bkataru
bkataru force-pushed the fix/rustsec-2026-0285 branch from 6635ac4 to a9a9c29 Compare October 6, 2026 13:27
bkataru added a commit that referenced this pull request Oct 6, 2026
async-trait 0.1.89 (src/expand.rs:69) pushes a bare #[must_use] onto
every generated async-trait fn. Those fns return Pin<Box<dyn Future>>,
which is itself #[must_use], so clippy 1.99.0's new double_must_use lint
fires and -D warnings turns it into an error.

0.1.92 removes that push. Lockfile-only: the declared range is already
"0.1", so no Cargo.toml change.

Verified on origin/main @ 46b8118 with clippy 1.99.0 (ci.yml:36 flags):
  async-trait 0.1.89 -> cargo clippy --workspace --exclude eruka-web -- -D warnings
      exit=101, 4 sites
  async-trait 0.1.92 -> same command
      exit=0, 0 sites

Fixes #86. Unblocks #82 (RUSTSEC-2026-0285).
@bkataru
bkataru force-pushed the fix/rustsec-2026-0285 branch from a9a9c29 to 520c03f Compare October 21, 2026 18:37
…ly bump

This clears eleven of the fourteen findings `cargo audit` reports with the
repository's suppressions applied (twelve of twenty-one without them), across
twelve distinct advisories:

  quinn-proto       0.11.15 -> 0.11.18   RUSTSEC-2026-0338/0339/0340/0341/0342
  rustls            0.23.39 -> 0.23.46   RUSTSEC-2026-0285/0346/0348/0349
  rustls-webpki     0.103.13 -> 0.103.16  RUSTSEC-2026-0382
  webpki-root-certs 1.0.7   -> 1.0.10    RUSTSEC-2026-0383
  webpki-roots      1.0.7   -> 1.0.10    RUSTSEC-2026-0381

Each row lists the advisories that stop matching that copy. RUSTSEC-2026-0346
and RUSTSEC-2026-0349 also match the legacy `rustls 0.22.4` copy, which is not
moved here.

`aws-lc-rs` and `aws-lc-sys` move with `rustls 0.23.46`; they are forced by that
move, not incidental drift.

cargo audit on the resulting lockfile reports 3 findings, down from 14 with the
repository's suppressions applied and 9 instead of 21 without them.

The remaining three are the legacy `rustls 0.22.4` and `rustls-webpki 0.102.8`
copies. Their dependency requires `rustls ^0.22` and that series has no patched
release, so they are reported rather than suppressed: both are reachable from
the CLI, and suppressing a reachable advisory would hide it.

RUSTSEC-2026-0285 is removed from .cargo/audit.toml. The reason recorded for it
described the copy as pinned below the patched floor; the resolver moves that
copy to 0.23.46 inside its own range, and with the bump applied the advisory
matches no locked copy.
@bkataru
bkataru force-pushed the fix/rustsec-2026-0285 branch from 520c03f to 317be4c Compare October 21, 2026 18:39
@bkataru bkataru changed the title fix(deps): rustls 0.23.45 for RUSTSEC-2026-0285 fix(deps): clear the resolvable RUSTSEC advisories with a lockfile-only bump Oct 21, 2026
@bkataru

bkataru commented Oct 21, 2026 •

Copy link
Copy Markdown
Member Author

This branch was rebased onto current main and its advisory commit replaced, so the diff is now
two files instead of the 92-file, +8,621-line diff the branch carried.

The branch held 553 commits, 45 of them after the merge-base with main. Those 45 fall into
three classes, and the rebase treats them three different ways: 39 were reported as previously
applied upstream and skipped; the one advisory commit became empty when it was replayed against
the current lockfile and was dropped; and the five merge commits were flattened, their
constituents being among those 39. Nothing was dropped that was not already in main.

The replacement commit carries the measured bump set rather than a single rustls 0.23.45
move:

crate from to
quinn-proto 0.11.15 0.11.18
rustls 0.23.39 0.23.46
rustls-webpki 0.103.13 0.103.16
webpki-root-certs 1.0.7 1.0.10
webpki-roots 1.0.7 1.0.10

0.23.46 rather than 0.23.45, because RUSTSEC-2026-0346, -0348 and -0349 are patched only
at >= 0.23.46; the 0.23.45 floor clears RUSTSEC-2026-0285 alone.

cargo audit: 14 findings -> 3 with the repository's suppressions, 21 -> 9 without them. The
three that remain are the legacy rustls 0.22.4 / rustls-webpki 0.102.8 copies, tracked in
#153.

Two corrections are visible in this branch's history, both made before the diff was final: the
commit message first said "eight advisories" where its own table enumerates twelve, and this
comment's earlier wording gave the branch as a 45-commit line and did not account for the five
merge commits.

This branch has not been deployed

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