Dependency updates, with nothing to keep in step by hand - #150
Merged
Merged
Conversation
Replaces varve#2, which was closed rather than merged. That config enumerated cargo directories — `/`, `/crates/varve-core`, `/crates/varve` — and was already wrong when it was opened: `varve-producer` had shipped and was not in the list, and `varve-serve` has since joined it. A hand-maintained enumeration of crates is precisely the drift this repository gates against everywhere else. `mutation-scope.toml` exists because a hand-kept file list went stale and a mutant permitting yank suppression survived; the docs gate enumerates shipped binaries rather than naming them, after naming one of two. Merging a config with the same defect would have been odd. So: ONE cargo entry for the workspace. varve has a single root `Cargo.lock`, which `/` already covers — per-crate entries would raise duplicate, conflicting PRs against that one lockfile and would need adding to whenever a crate is. And `github-actions`, which the old config omitted and which is the ecosystem this repository most needs. Every workflow pins actions by full commit SHA, which is right for a project whose subject is supply-chain integrity and which means they go stale SILENTLY — there is no version constraint anywhere for anything to notice. Dependabot understands the SHA-plus-comment form and keeps them pinned while moving them forward. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu
avrabe
added a commit
that referenced
this pull request
Sep 16, 2026
A TLS 1.3 vulnerability published 2026-09-14, two days before this release would have shipped: rustls accepted handshake messages sent at the wrong encryption level when they followed a key-changing message in the same record. Patched in >= 0.23.45; unaffected below 0.23.13, so the fix is forward. It reaches varve through `ureq`, which varve-core uses to download, and through `wsc`. A release whose subject is verified supply chains cannot ship carrying a known vulnerability in the library that secures its downloads, so this belongs in v0.35.0 rather than in an exception or a later patch. Found by the loop rather than by a report, and the way it surfaced is worth recording: a docs-only PR (#111) and a config-only PR (#150) failed the IDENTICAL check. Two unrelated changes cannot cause one shared failure, so the cause was environmental — the advisory database had moved. main's last run is green only because it predates the advisory; main would fail this today. `cargo update -p rustls` alone did not move it and reported success; the version had to be named with `--precise 0.23.45`. Verified with the same tool CI runs: `cargo deny check advisories` goes from FAILED to `advisories ok`, and the workspace still builds with all 20 suites passing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu
avrabe
added a commit
that referenced
this pull request
Sep 17, 2026
…160) The config from #150 was right about WHAT to update and wrong about how many PRs to open for it. Its first run opened eight at once. That is expensive here specifically. This repository's ruleset requires a branch to be current before it merges, and its CI runs 30-40 minute mutation shards. So each merge knocked the remaining PRs out of date and restarted all of their CI — eight serial cycles is most of a day of runners for one week's updates, and eight open PRs is the exact backlog the maintainer asked to have cleared. Minor and patch updates now group into one PR per ecosystem. Majors are left ungrouped on purpose: a breaking change needs its own reading, and bundling it beside a set of patch bumps is how it gets approved without one. Of the first eight PRs, six were majors. The config also now says, beside the actions entry, where a green PR is weak evidence — and for two actions, none at all: - setup-oras is used only by deposit-layer.yml, which runs only on workflow_dispatch, so PR CI never executes it; - cosign-installer is exercised on PRs by ci.yml, but its SIGNING use is in release.yml, which runs on a tag. A green PR proves the installer installs, not that `cosign sign-blob` still works. Both surface only at a release or a deposit — the point of no return that v0.34.3 records the cost of — so the note says to exercise those paths deliberately before merging a major. Claude-Session: https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces #2, which I closed rather than merged.
That config enumerated cargo directories by hand —
/,/crates/varve-core,/crates/varve— and was already wrong when it was opened:varve-producerhad shipped and was missing, and
varve-servehas since joined it. Ahand-maintained list of crates is the drift this repository gates against
everywhere else (
mutation-scope.tomlexists because one went stale; the docsgate enumerates shipped binaries after naming one of two).
/. Single rootCargo.lock, so per-crate entrieswould raise duplicate conflicting PRs against the same lockfile — and would
need adding to whenever a crate is.
github-actions, which [temper] Configuration update #2 omitted and which matters most here. Everyworkflow pins actions by full commit SHA, which is correct for this project
and means they go stale silently: there is no version constraint anywhere for
anything to notice.