Summary
The Netquirk monitoring backend (rust + libsql 0.6) currently pulls hyper-rustls 0.25.0 → rustls 0.22.4 → rustls-webpki 0.102.8, which is flagged by four high-severity advisories:
- RUSTSEC-2026-0049 (CRL Distribution Point matching)
- RUSTSEC-2026-0098 (URI name constraints)
- RUSTSEC-2026-0099 (wildcard name constraints)
- RUSTSEC-2026-0104 (CRL parsing panic)
hyper-rustls 0.26+ already moved to rustls 0.23 (which uses rustls-webpki 0.103.x and clears all four). libsql 0.6 hard-pins hyper-rustls = "^0.25", so the fix has to land in libsql itself (or a libsql 0.7+).
What we've done locally
- Confirmed
libsql 0.6 (current stable on crates.io), libsql 0.9.30 (also stable), and libsql 0.10.0-pre.4 all still pull the vulnerable chain — hyper-rustls 0.25.0 is the constraint, not libsql.
- Backported the
rustls 0.22 → 0.23 portion of upstream commit rustls/hyper-rustls@731d19e onto the hyper 0.14 line (the version line libsql 0.6 still needs). Diff is a 4-line Cargo.toml edit + a version bump to 0.25.1.
- Verified it locally:
cargo check passes on hyper 0.14 + rustls 0.23 + tokio-rustls 0.26.- In the Netquirk monitoring backend,
[patch.crates-io] hyper-rustls = { git = "netquirk/hyper-rustls", branch = "netquirk/rustls-0.23" } makes cargo audit drop all four rustls-webpki 0.102.8 advisories.
- All
libsql integration tests pass (in-memory + remote).
connect_remote against the live Bunny libSQL endpoint succeeds.
Request
Please bump the optional hyper-rustls dep in libsql (currently ^0.25) to ^0.26 (or whatever is current) so downstream consumers — including the Netquirk monitoring backend — get rustls 0.23 and the patched rustls-webpki without needing a [patch.crates-io] override.
If a hyper 0.14 compatible line of hyper-rustls is no longer maintained for the ^0.25 range, even just bumping the existing ^0.25 pin to ^0.25, <0.26 would force Cargo to look at 0.25.1 once you publish it; we'd much rather see ^0.26 so we can drop our patch.
Tracking issue on our side: NET-883 (parent NET-868).
Thanks!
Summary
The Netquirk monitoring backend (rust + libsql 0.6) currently pulls
hyper-rustls 0.25.0→rustls 0.22.4→rustls-webpki 0.102.8, which is flagged by four high-severity advisories:hyper-rustls 0.26+already moved torustls 0.23(which usesrustls-webpki 0.103.xand clears all four).libsql 0.6hard-pinshyper-rustls = "^0.25", so the fix has to land inlibsqlitself (or alibsql 0.7+).What we've done locally
libsql 0.6(current stable on crates.io),libsql 0.9.30(also stable), andlibsql 0.10.0-pre.4all still pull the vulnerable chain —hyper-rustls 0.25.0is the constraint, notlibsql.rustls 0.22 → 0.23portion of upstream commitrustls/hyper-rustls@731d19eonto thehyper 0.14line (the version linelibsql 0.6still needs). Diff is a 4-lineCargo.tomledit + a version bump to0.25.1.cargo checkpasses onhyper 0.14 + rustls 0.23 + tokio-rustls 0.26.[patch.crates-io] hyper-rustls = { git = "netquirk/hyper-rustls", branch = "netquirk/rustls-0.23" }makescargo auditdrop all four rustls-webpki 0.102.8 advisories.libsqlintegration tests pass (in-memory + remote).connect_remoteagainst the live Bunny libSQL endpoint succeeds.Request
Please bump the optional
hyper-rustlsdep inlibsql(currently^0.25) to^0.26(or whatever is current) so downstream consumers — including the Netquirk monitoring backend — getrustls 0.23and the patchedrustls-webpkiwithout needing a[patch.crates-io]override.If a hyper 0.14 compatible line of
hyper-rustlsis no longer maintained for the^0.25range, even just bumping the existing^0.25pin to^0.25, <0.26would force Cargo to look at0.25.1once you publish it; we'd much rather see^0.26so we can drop our patch.Tracking issue on our side: NET-883 (parent NET-868).
Thanks!