From e697dc68e8b572a917fd95b820c2d3770be8e277 Mon Sep 17 00:00:00 2001 From: Claude Date: Tue, 1 Sep 2026 23:38:08 +0000 Subject: [PATCH 1/5] fix(ci): pin the MSRV job back to a Rust version that exists Dependabot moved `dtolnay/rust-toolchain` from 1.94.1 to 1.100.0 in #1384. That ref is a Rust version, not a release of the action, so the bump was decided by comparing numbers: 1.100.0 is the larger, and it is also a Rust release that does not exist. Every pull request in the repository has failed since, in `Test Stable (MSRV)`, at error: could not download nonexistent rust version `1.100.0` before a line was compiled. The declared floor never moved -- `rust-version = "1.94"` in the root Cargo.toml -- so the pin goes back to 1.94.1 and the two agree again, which is the pairing the job's own comment asks for. The updater is told to leave this one alone as well, because nothing about the failure was specific to 1.100.0: any ref it picks is a toolchain it cannot know exists, matching a floor it cannot see. Raising the MSRV stays a two-line change made by hand, in the two places that have to move together. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SXRWTrDqjsPYAZMHBgF7uZ --- .github/dependabot.yml | 9 +++++++++ .github/workflows/main.yml | 10 +++++++++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 5a2a86428..a6e8f5baf 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -59,6 +59,15 @@ updates: actions: patterns: - "*" + # The MSRV job pins `dtolnay/rust-toolchain` by a ref that names a *Rust + # version*, not a release of the action. The updater cannot see that: it + # compares the numbers, finds 1.100.0 larger than 1.94.1, and pins a + # toolchain `rustup` then 404s on — which is what happened, and it failed + # every pull request in the repository at toolchain install. The floor is + # raised by hand, next to `rust-version` in the root Cargo.toml, which is + # the pairing the job's own comment asks for. + ignore: + - dependency-name: dtolnay/rust-toolchain # No docker entry: the Dockerfile builds `FROM rust:alpine` and `FROM # scratch`, neither of which carries a version for the updater to bump. Add diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 32019201f..1476a8248 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -429,7 +429,15 @@ jobs: # Pinned rather than `@stable`: this version is the workspace MSRV # (`rust-version` in the root Cargo.toml). To raise the floor, bump both # together — a floating `stable` would silently let the declared MSRV rot. - - uses: dtolnay/rust-toolchain@1.100.0 + # + # And it is not Dependabot's to raise. This ref is a Rust version, not a + # release of the action, so the updater bumps it by comparing numbers and + # has no way to know the toolchain has to exist and has to match the + # declared floor. It once moved this to 1.100.0 — numerically the largest + # ref, a Rust release that does not exist — and every pull request in the + # repository failed at `rustup`, before a line was compiled. The + # `dependabot.yml` entry beside this one is what keeps the pin ours. + - uses: dtolnay/rust-toolchain@1.94.1 # The pre-built nextest binary is toolchain-independent — it drives this # MSRV cargo the same way it drives the nightly one. - name: Install protoc and cargo-nextest From 77d0eef648ba4ee1b0d569ef13a7692381ab580a Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 00:12:12 +0000 Subject: [PATCH 2/5] docs(ci): note what the Dependabot ignore also freezes An ignore is per dependency rather than per use, so excluding `dtolnay/rust-toolchain` also stops the SHA pin in `signal-durability-nightly.yml` being refreshed. That is collateral rather than intent: the pin anchors reproducibility for a nightly job rather than tracking a floor that has to move, so it going stale costs less than the MSRV job breaking every week. Bump it by hand if a fix in the action ever matters there. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SXRWTrDqjsPYAZMHBgF7uZ --- .github/dependabot.yml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index a6e8f5baf..83102e628 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -68,6 +68,12 @@ updates: # the pairing the job's own comment asks for. ignore: - dependency-name: dtolnay/rust-toolchain + # This also stops the SHA pin in `signal-durability-nightly.yml` being + # refreshed, which is collateral rather than intent: an ignore is per + # dependency, not per use. That pin is a reproducibility anchor for a + # nightly job rather than a floor that has to track anything, so it going + # stale costs less than the MSRV job breaking every week. Bump it by hand + # if a fix in the action ever matters there. # No docker entry: the Dockerfile builds `FROM rust:alpine` and `FROM # scratch`, neither of which carries a version for the updater to bump. Add From d053361e7885da7d6abf307ce9dd24bddf1cc3cc Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 05:34:05 +0000 Subject: [PATCH 3/5] fix(ci): let cargo-deny pass on the build-script duplicate versions `bans` has been failing on every pull request, `main` included, on three duplicate entries: `getrandom` 0.3.4/0.4.3, `prettyplease` 0.2.37/0.3.0, and `r-efi` 5.3.0/6.0.0. None can be closed from our manifests. Each pair is two incompatible majors pulled by different parents: the workspace is on `getrandom` 0.4 through rand 0.10, while the `tempfile` inside buffa's codegen is on 0.3, and `r-efi` is whichever one each `getrandom` picked. Choosing either side leaves the other parent unsatisfied, and no version of ours is a parent of any of them. What decides it is where they are reached from: only through `buffa-build`, which every crate using it declares under `[build-dependencies]`. A build script runs at compile time and links into no shipped binary -- the same argument the proc-macro skips beneath these already make, which is why they sit next to each other. Also drops the RUSTSEC-2026-0150 ignore. `audiopus` is no longer anywhere in `Cargo.lock`, even under `--all-features`, so the entry excused a crate that had left the graph and cargo-deny was reporting it as `advisory-not-detected`. An ignore outliving the crate it excuses is how a real advisory gets waved through later under a name nobody rechecked. Verified with the CI command itself, cargo-deny 0.20.2, the version `taiki-e/install-action` resolves: `advisories ok, bans ok, licenses ok, sources ok`. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SXRWTrDqjsPYAZMHBgF7uZ --- deny.toml | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/deny.toml b/deny.toml index 9b623d4a4..9149b406a 100644 --- a/deny.toml +++ b/deny.toml @@ -12,12 +12,16 @@ exclude-dev = true [advisories] version = 2 -# Only `unmaintained` notices are listed below, and only where no upgrade -# exists. A real vulnerability advisory must be resolved by a version bump, -# never by an entry here. -ignore = [ - { id = "RUSTSEC-2026-0150", reason = "audiopus_sys, reached through the optional `voip-libopus` feature via opus 0.3. Upstream is dormant with no fork on crates.io; the crate is a thin libopus FFI shim that we build but do not drive directly." }, -] +# Only `unmaintained` notices belong here, and only where no upgrade exists. A +# real vulnerability advisory must be resolved by a version bump, never by an +# entry here. +# +# Empty on purpose. RUSTSEC-2026-0150 (audiopus_sys) was listed until the crate +# left the graph entirely -- `audiopus` appears nowhere in Cargo.lock now, even +# under `--all-features` -- and cargo-deny reports a stale ignore as +# `advisory-not-detected`. An ignore outliving the crate it excuses is how a +# real advisory gets waved through later under a name nobody rechecked. +ignore = [] [licenses] version = 2 @@ -75,6 +79,19 @@ skip = [ { name = "getrandom", version = "=0.2.17" }, { name = "rand_core", version = "=0.6.4" }, + # Build-script-side duplicates, all reached only through `buffa-build`, + # which every crate that uses it declares under `[build-dependencies]`. + # Like the proc-macro entries below, they cost build time only: a build + # script runs at compile time and links into no shipped binary. And none of + # them can be collapsed from here, because each pair is two incompatible + # majors pulled by different parents -- the workspace is on `getrandom` 0.4 + # via rand 0.10, while `tempfile` inside the codegen is on 0.3, and `r-efi` + # is simply whichever one each `getrandom` chose. Collapses when buffa + # upgrades, not on anything we can do to our own manifests. + { name = "getrandom", version = "=0.3.4" }, + { name = "prettyplease", version = "=0.2.37" }, + { name = "r-efi", version = "=5.3.0" }, + # Proc-macro-side duplicates. They cost build time only — proc macros run # at compile time and never link into the produced binary. { name = "darling", version = "=0.21.3" }, From 86716c4f0f5482b413ee7242098194f6fe35e8dd Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 05:34:05 +0000 Subject: [PATCH 4/5] chore(deps): move off the yanked chacha20 0.10.1 cargo-deny reports it as a yanked crate, reached through rand 0.10.2 and so present in every build. 0.10.2 is a patch release on the same line and the only lock entry that moves. Workspace lib tests pass on it: 5245 tests, no failures. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SXRWTrDqjsPYAZMHBgF7uZ --- Cargo.lock | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Cargo.lock b/Cargo.lock index 1e40312e3..1d46476a9 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -547,9 +547,9 @@ checksum = "f079e83a288787bcd14a6aea84cee5c87a67c5a3e660c30f557a3d24761b3527" [[package]] name = "chacha20" -version = "0.10.1" +version = "0.10.2" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d524456ba66e72eb8b115ff89e01e497f8e6d11d78b70b1aa13c0fbd97540a81" +checksum = "65c35e4b699c7e15ccbe7ee35c005e4fc0a278d22238a2857e6ce2dadeda1b06" dependencies = [ "cfg-if", "cpufeatures 0.3.0", From abe12629f37da1bb9216615582791cdb12361fc0 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 05:41:06 +0000 Subject: [PATCH 5/5] docs(ci): say why the lock's rand_core entry is not a second path `Cargo.lock` carries a `rand_core` 0.9.5 entry listing `getrandom 0.3.4` as a dependency, which reads like a runtime route into the shipped graph and makes the skip beside it look like it is excusing a duplicate that ships. Nothing reaches that rand_core: `cargo tree -i rand_core@0.9.5 --target all` prints nothing, on any target. The entry is stale, and the build-dependency route is the only one there is. Worth writing down because a reviewer read it the other way within an hour of the skip landing, and the lock will keep saying it. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SXRWTrDqjsPYAZMHBgF7uZ --- deny.toml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/deny.toml b/deny.toml index 9149b406a..5676bbed7 100644 --- a/deny.toml +++ b/deny.toml @@ -88,6 +88,13 @@ skip = [ # via rand 0.10, while `tempfile` inside the codegen is on 0.3, and `r-efi` # is simply whichever one each `getrandom` chose. Collapses when buffa # upgrades, not on anything we can do to our own manifests. + # + # `Cargo.lock` invites a misreading here: it carries a `rand_core` 0.9.5 + # entry that lists `getrandom 0.3.4` as a dependency, which reads like a + # second, runtime path into the shipped graph. Nothing reaches that + # rand_core -- `cargo tree -i rand_core@0.9.5 --target all` prints nothing + # at all -- so the lock entry is stale and the build-dependency route below + # is the only one. Check with `cargo tree -i`, not by grepping the lock. { name = "getrandom", version = "=0.3.4" }, { name = "prettyplease", version = "=0.2.37" }, { name = "r-efi", version = "=5.3.0" },