Repository navigation
fix(deps): bump event-listener, chacha20 and spin in Cargo.lock - #198
Merged
Merged
Conversation
cargo audit reports event-listener 5.4.1 as unsound (RUSTSEC-2026-0221, patched in 5.4.2) and chacha20 0.10.1 and spin 0.9.8 as yanked. Update the three to 5.4.2, 0.10.2 and 0.9.9 with cargo update -p; nothing else in the lockfile changes. cargo audit still reports RUSTSEC-2026-0459 (libsqlite3-sys 0.30.1). No released sqlx accepts the patched libsqlite3-sys 0.39 (0.8.6 needs ^0.30.1, 0.9.0 caps below 0.38), so that one needs an owner decision. cargo test --locked: all suites pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0136P7ZnmBahbhfkFEP6ark4
Contributor
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters: 1
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including
 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
Owner
Author
|
No dependency bump can fix the remaining advisory yet. The patched Generated by Claude Code |
hyperpolymath
added a commit
that referenced
this pull request
Nov 10, 2026
…SQLite (RUSTSEC-2026-0459) (#199) ## Summary `Dependency audit` (`cargo audit`) fails on `main` since 2026-11-10 (run 449 at `bbbc433`), and so on each open pull request, for example #197. The cause is a new advisory: RUSTSEC-2026-0459 (CVE-2026-119375) in `libsqlite3-sys` 0.30.1, the crate that carries the SQLite source. The patched crate is 0.39.0 or later. This pull request repairs the dependency. It does not add an ignore entry: it removes the one that the file had. ## Why a commit of sqlx, and not a release No crates.io release of sqlx permits the patched crate: | sqlx | `libsqlite3-sys` that it permits | Result | |---|---|---| | 0.8.6 (the version on `main`) | 0.30 | `cargo update -p libsqlite3-sys` moves 0 packages | | 0.9.0 (the latest release) | `>=0.30.1, <0.38.0` | the best version is 0.37.0, which the advisory lists as affected | | `main` since commit `10462fa` (2026-11-08, sqlx pull request 4502) | `>=0.30.1, <0.40.0` | 0.39.1, patched | Upstream has the repair, and it is not in a release. This change takes sqlx from that commit, pinned by its full hash. This crate has 2 git dependencies of the same form already (`gitbot-shared-context`, `echidna-core`). **The trade.** The crate then depends on 1 commit of sqlx that is not a release: sqlx 0.9.0 plus the commits on its `main` branch up to `10462fa`. The other option is an ignore entry in `.cargo/audit.toml` until sqlx makes a release. The exposure is low in each case: the advisory needs a party who can write the database file and its `-wal` file, and this crate opens only its own database. The owner asked for the repair and not for the ignore entry. **The exit.** At the first sqlx release after 0.9.0, the line in `Cargo.toml` goes back to `version = "..."`. A comment on the line says this. ## Relation to #198 #198 moves the 3 crates that have warnings (`event-listener`, `chacha20`, `spin`) and says that it does not repair RUSTSEC-2026-0459. This pull request repairs RUSTSEC-2026-0459 and does not move those 3 crates. The 2 changes do not overlap in content, but each one changes `Cargo.lock`. The one that merges second needs `main` merged in and its `cargo update` commands run again. ## Changes - `Cargo.toml`: sqlx from the upstream commit `10462fa4414c6c7f1ed1d39bb31678e3b726878c`. The feature `runtime-tokio-rustls` does not exist in 0.9. In 0.8.6 it was `runtime-tokio` plus `tls-rustls-ring`, and `tls-rustls-ring` was `tls-rustls-ring-webpki`. The line now names `runtime-tokio` and `tls-rustls-ring-webpki`, so the feature set is the same. - `Cargo.lock`: `cargo update -p sqlx`, then `cargo update -p libsqlite3-sys`. `libsqlite3-sys` is 0.39.1. The crates that sqlx 0.8 needed and sqlx 0.9 does not need go out, `rsa` among them. - `.cargo/audit.toml`: the ignore entry for RUSTSEC-2023-0071 (`rsa`) is removed. Its reason was that `rsa` is in `Cargo.lock` only through the MySQL backend of sqlx 0.8. `rsa` is not in `Cargo.lock` any more. The list is empty. - No source file changes. The crate compiles against sqlx 0.9 as it is. ## Testing Run locally with Rust 1.99.0 (the toolchain of `rust-toolchain.toml`), at `1a6908e`: - `cargo audit` (cargo-audit from crates.io, the tool of the CI check): - on `main`: `error: 1 vulnerability found!` (RUSTSEC-2026-0459). This is the result of CI. - on this branch: 0 vulnerabilities, exit 0. The 3 allowed warnings are the same as before (`event-listener`, `chacha20`, `spin`). - `cargo test --locked`: exit 0, 0 failed. Unit tests 214; `integration_tests` 32; `lifecycle` 23; `live_echidna` 5; `property_tests` 12; `protocol_contract` 12; `seam_test` 15; `smoke` 13; doc tests 2 passed and 1 ignored. - `cargo clippy --locked --all-targets -- -D warnings`: exit 0 (run on a scratch copy with the same `Cargo.lock` and the same sqlx line). - `cargo fmt --check`: exit 0. - `cargo metadata --locked`: exit 0. Not verified: - The PostgreSQL path at run time. The tests use SQLite (`sqlite::memory:`). The PostgreSQL code compiles. - The `live_echidna` tests return at once when their environment variables are not set, so their 5 passes do not show a live run. - The container build (`Containerfile`). - The behaviour changes of sqlx 0.9 that the compiler does not show. The sqlx changelog lists them for 0.9.0; 2 that can matter here: `tracing` log spelling, and the output of the `query!()` macros for some PostgreSQL queries. ## After the merge - #197 gets `main` merged in, and its `Dependency audit` check can pass. - The fleet copy (`bots/echidnabot/` in gitbot-fleet) takes this change with the next pin move, because `Cargo.toml` and `Cargo.lock` are in its include list. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0136P7ZmiFSCoB3UR9Kk56rK Co-authored-by: Claude <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.
Why
cargo audit(.github/workflows/cargo-audit.yml) fails on main with 1 vulnerability and 3 warnings.What
cargo update -p event-listener -p chacha20 -p spin. OnlyCargo.lockchanges:event-listenerchacha20spinNot fixed here: RUSTSEC-2026-0459
libsqlite3-sys 0.30.1comes throughsqlx 0.8.6. The patch is inlibsqlite3-sys >= 0.39.0, but no released sqlx accepts it:sqlx-sqlite 0.8.6requires^0.30.1, and0.9.0requires<0.38.0. So no version bump can fix it yet. The advisory affects only a process that opens a database together with a-walfile that a less trusted party could have written. How to handle it is an owner decision, socargo auditstays red until then.Testing
cargo auditwith this change: 0 warnings. Only RUSTSEC-2026-0459 remains.cargo test --locked: every suite passes (lib: 214 passed).Generated by Claude Code