tiberius 0.12.3 — its latest release — pins rustls 0.21, whose rustls-webpki 0.101 carries three unfixed certificate-verification advisories (RUSTSEC-2026-0098, -0099, -0104). The fix needs webpki ≥0.103; there's no patched 0.101. That's on the connection carrying every message that crosses the Hub, in full and unredacted.
I started writing a reachability argument to ignore them, then stopped — three vulnerabilities in one verification path isn't a case for a carefully-worded ignore. So I built tiberius with no TLS backend at all. That removes the vulnerable crates from the graph entirely: cargo deny now passes with no ignore, and no future change can quietly start using them. native-tls wasn't an option — spec/17 §8.2 forbids openssl and spec/18 §2.3 depends on there being no system TLS library.
The consequence is honest and enforced: SQL_ENCRYPT=Yes is a connection failure, naming the section, rather than a silent plaintext connection. An operator who asked for TLS and quietly got none would have no way to find out.
This blocks production use against Azure SQL, alongside the second blocker — managed-identity authentication isn't implemented, so only password auth works. Both are spec/12 §5.8 and tracked as P6.6. Local SQL Server over plaintext, which is what P6.5 will test, is unaffected. The fix is upstream and one line here when tiberius moves to rustls 0.23.
tiberius 0.12.3 — its latest release — pins rustls 0.21, whose rustls-webpki 0.101 carries three unfixed certificate-verification advisories (RUSTSEC-2026-0098, -0099, -0104). The fix needs webpki ≥0.103; there's no patched 0.101. That's on the connection carrying every message that crosses the Hub, in full and unredacted.
I started writing a reachability argument to ignore them, then stopped — three vulnerabilities in one verification path isn't a case for a carefully-worded ignore. So I built tiberius with no TLS backend at all. That removes the vulnerable crates from the graph entirely: cargo deny now passes with no ignore, and no future change can quietly start using them. native-tls wasn't an option — spec/17 §8.2 forbids openssl and spec/18 §2.3 depends on there being no system TLS library.
The consequence is honest and enforced: SQL_ENCRYPT=Yes is a connection failure, naming the section, rather than a silent plaintext connection. An operator who asked for TLS and quietly got none would have no way to find out.
This blocks production use against Azure SQL, alongside the second blocker — managed-identity authentication isn't implemented, so only password auth works. Both are spec/12 §5.8 and tracked as P6.6. Local SQL Server over plaintext, which is what P6.5 will test, is unaffected. The fix is upstream and one line here when tiberius moves to rustls 0.23.