#2273·libsql

netquirk/monitoring-backend NET-883: please bump hyper-rustls to >=0.26 in libsql 0.6 (rustls 0.22 → 0.23) to clear rustls-webpki 0.102.8 advisories

Author: JKJamesonCreated Aug 17, 2026Updated Aug 17, 2026

Summary

The Netquirk monitoring backend (rust + libsql 0.6) currently pulls hyper-rustls 0.25.0rustls 0.22.4rustls-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

  1. 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.
  2. 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.
  3. 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!