Repository navigation
3.x.x: update rustls-webpki, webpki-roots and the fuzz lockfile's rustls for six RustSec advisories - #777
Merged
Conversation
…tls for six RustSec advisories cargo deny fails on RUSTSEC-2026-0382 (rustls-webpki < 0.103.16) and RUSTSEC-2026-0381 (webpki-roots < 1.0.10), and the fuzz lockfile still has rustls 0.23.45 (RUSTSEC-2026-0346, -0347, -0348 and -0349); the root lockfile already has 0.23.46. Move each to its first fixed patch release with cargo update --precise, as #354 did. No other dependency changes. The same fix for 3.0.0 is in #776. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Member
Author
|
Re-triggering CI: candidate_storm_restart's statement-cost check caught one extra read-only periodic snapshot transaction in the storm run (65 vs 72 statements; the 7-statement diff is the REPEATABLE READ READ ONLY count/partition-headroom/orphan check). Timing flake, unrelated to the lockfile change. |
kiwidream
added a commit
that referenced
this pull request
Oct 26, 2026
…knowledgement bound from dropping a disposition poll's connection (#781) * main: update tokio to 1.53.3 for RUSTSEC-2026-0386 The Dependency audit job (`cargo deny --locked check`) fails on RUSTSEC-2026-0386: tokio 1.53.1's safe `AsyncFd` constructors violate I/O safety. Move tokio to its first fixed patch release, 1.53.3, in the root and fuzz lockfiles, as #777 did for the TLS advisories. Nothing in the workspace uses `AsyncFd`. Only tokio's version and checksum change. `cargo update -p tokio --precise 1.53.3` also moved the windows-sys edges of four unrelated crates (errno, quinn-udp, rustix, tempfile) from 0.61.2 to 0.52.0, so the edit keeps those as they were; both lockfiles pass `cargo metadata --locked`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * main: keep the block-proof acknowledgement bound from dropping a disposition poll's connection b574_ack_cap's a_captured_proof_is_answered_at_the_cap_and_credited_after_its_landing failed on #780 with `proxy connection task failed: Connection reset by peer (os error 104)`, which the ledger execution proxy reported when the fixture closed. `deferred_share_disposition` wrapped each poll's checkout and SQL in `timeout_at(bound, ...)`. When the bound fell inside the checkout, during the pool's `before_acquire` ping of a connection idle for 100 ms or a new connection's setup, SQLx dropped the raw connection with the reply unread, and the kernel answered with a TCP reset. The test proxy reports that as a failed connection; PostgreSQL logs it as a client reset, and the pool loses a healthy connection. Each poll now runs in its own task, as the duplicate probe and enqueue do (#574), and only the wait for it is bounded. Answers, phases and `block_proof_ack_capped_total` are unchanged. A poll still running at the bound, or when the submission is cancelled, finishes on its own and returns its connection, so `database_pool_acquire_seconds` records its checkout when it ends instead of as a cancelled failure. Two acquire tests and docs/prism-pool-acquire-metrics.md now say so. A bound already past on entry, as for a #657 capture that committed in the share grace, starts no poll: the old code's poll there could only be cut off. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2 of 7 tasks
RobertClarke
added a commit
that referenced
this pull request
Oct 26, 2026
* 3.x.x: version 3.1.0, and tokio 1.53.3 for RUSTSEC-2026-0386 VERSION, the workspace version and both lockfiles' workspace members move to 3.1.0. tokio moves from 1.53.1 to 1.53.3, its first fixed patch release for RUSTSEC-2026-0386, in the root and fuzz lockfiles, as main took it in #781. cargo update -p tokio --precise 1.53.3 also moved the windows-sys edges of four unrelated crates to 0.52.0, so, as in #781, only tokio's version and checksum change. Nothing in the workspace uses AsyncFd. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * 3.x.x: 3.1.0 release notes, and 3.x.x as the production line doc/release-notes-3.1.0.md covers the changes since 3.1.0-rc.1 (#777's TLS updates and the tokio update), the upgrade from rc.1 (a binary swap) and from 3.0.0 or 3.0.0-rc.6 (#773's pre-migrate, the binary, then the optional dual-writer cutover), and the known issues carried from rc.1 plus #779's L3 failures and the acknowledgement bound's connection drop that main fixes in #781. The README banner, the development-line note and the migration guide now say 3.x.x is the production line, deployed from the v3.1.0 tag. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * 3.x.x: 3.1.0 notes: review fixes The migration guide and ledger operations cite the released 3.0.0 notes' D5 boundary at v3.0.0, not this branch's pre-release copy. The development-line note's header no longer calls the line "not a release". The 3.1.0 notes say a dual-writer-off frontend serves as 3.0's does once the migrations are applied, tell a 2.0.x upgrade that #765's guard is not needed, and list the required prism-dual-writer lane and rc.1's evidence set under Verification. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * 3.x.x: 3.1.0 notes: second review round The #779 known issue counts the async preset's failed repeats (four of six) and names the sync preset rather than a repeat's job. The cutover step names node-identity repersonalise and defers the cutover itself to the pair's runbook, as rc.1's notes do. Verification says docs changed since rc.1 too. The development-line note says 3.0.x is not an ancestor of 3.1.0, and the migration guide no longer implies the 3.0.0 candidates were a supported production upgrade. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * 3.x.x: 3.1.0 notes: rewrap two lines Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.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
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.
The
Dependency auditjob (cargo deny --locked check) fails on six new RustSec advisories in the TLS crates. This moves each crate to its first fixed patch release withcargo update --precise, as #354 did for RUSTSEC-2026-0285.No other dependency changes. The same fix for 3.0.0 is in #776.
Checked locally
cargo deny --locked checkreports advisories, bans, licenses and sources ok.cargo check --locked --workspace --all-targetscompiles.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.