hyper-rustls 0.25 pin transitively forces rustls-webpki 0.102.x, which has unpatchable advisories (incl. one high)

[pranavraja99]

Summary

libsql's tls feature (which is on by default) pins hyper-rustls = "0.25". That version line only ever depended on rustls 0.22, which in turn requires rustls-webpki ^0.102. Because 0.102.8 is the last release in the 0.102 line, and the relevant fixes only landed in 0.103.10 / 0.103.12 / 0.103.13, every downstream consumer of libsql inherits four rustls-webpki advisories with no reachable fix.

The chain

libsql 0.9.30 (tls, default)
  -> hyper-rustls 0.25.0   (only 0.25.x release)
    -> rustls 0.22.4       (last 0.22.x release)
      -> rustls-webpki ^0.102 -> 0.102.8   (last 0.102.x release)

Every link is already at its ceiling, so no cargo update can resolve this.

Advisories inherited

Advisory	Severity	Fixed in
GHSA-82j2-j2ch-gfr8 — DoS via panic on malformed CRL BIT STRING	high (CVSS 7.5)	0.103.13
GHSA-pwjx-qhcg-rvj4 — CRLs not authoritative by Distribution Point	medium	0.103.10
GHSA-965h-392x-2mh5 — URI name constraints incorrectly accepted	low	0.103.12
GHSA-xgp8-3hg3-c2mh — name constraints accepted for wildcard certs	low	0.103.12

To be clear about impact: we assessed the two CRL ones as not reachable through libsql, since rustls only parses CRLs when they're explicitly supplied via with_crls(), and neither libsql nor hyper-rustls 0.25 ever does. So this is primarily a dependency-hygiene / compliance problem rather than an exploitable one — but it still surfaces as an unresolvable high-severity Dependabot alert in every downstream repo, which is painful for anyone under SOC2-style "no open highs" policies. We ended up having to dismiss them with written justification.

Why it isn't a one-line bump

hyper-rustls moved to rustls 0.23 (and thus webpki 0.103) in 0.26, but 0.26+ also requires hyper 1.x. libsql is still on hyper = "0.14":

https://github.com/tursodatabase/libsql/blob/main/libsql/Cargo.toml#L20-L21

So closing this properly means a hyper 0.14 → 1.x migration for the remote/sync HTTP client. Confirmed still present on main, and on 0.10.0-pre.4.

Possible options, roughly in order of effort

1. Migrate to hyper 1.x + hyper-rustls 0.27. The real fix; also unblocks a lot of other modernization.
2. Swap the TLS stack for rustls 0.23 directly behind libsql's own connector, decoupling from hyper-rustls' hyper requirement.
3. Interim mitigation — drop tls from default. Consumers that only use local databases (Builder::new_local) currently pull the whole rustls 0.22 stack for nothing. Notably tls is already independent: remote, sync, and replication do not depend on it, so making it opt-in would be a small change that lets local-only users escape these advisories entirely. It is technically a breaking change for anyone relying on defaults for remote TLS, so it'd want a minor-version note.

Happy to put up a PR for (3) if that's a direction you'd accept — it's the one that would unblock downstream consumers soonest. (1) looks like it needs a maintainer to scope.

Environment

• libsql 0.9.30 (also verified against main and 0.10.0-pre.4)
• Discovered via Dependabot on a downstream Rust project that uses libsql only through Builder::new_local