Security problems with Rust crate `tiberius` (via connector_arrow) plus options for drop-in replacement

[joelparkerhenderson]

Problem

This project depends on the Rust crate tiberius which has security problems and maintenance problems. Specifics below.

Solution

There are two recent forks of the crate that provide the security updates and PRs.

• mssql — maintained by Joel Henderson (me)
• tiberius-ng — maintained by Matt Jackson

Either fork is fine IMHO. You'll want to test them because they're both quite new. I prefer the name mssql because I work with Microsoft extensively and I'm working with their security teams; Matt prefers tiberius-ng name because it's similar.

Dependency chain note

Unlike a plain tiberius-using project, this isn't a same-repo drop-in rename. prqlc's SQL Server
support goes through connector_arrow
(prqlc/prqlc/Cargo.toml:114), and connector_arrow::tiberius::TiberiusConnection<S> hardcodes
client: tiberius::Client<S> — the concrete tiberius crate type, not a generic. prqlc also
depends on tiberius directly (prqlc/prqlc/Cargo.toml:126), but only to construct the
tiberius::Client it hands to that connector in the integration test runner
(prqlc/prqlc/tests/integration/dbs/runner.rs).

So switching prqlc alone from tiberius to mssql won't compile — mssql::Client<S> and
tiberius::Client<S> are different Rust types even though their APIs match. The fix needs to land
in connector_arrow first: a new mssql module mirroring its existing tiberius one (the two
crates' APIs are compatible, so this is a mechanical port, not a rewrite).

I've opened that as a PR: aljazerzen/connector_arrow#81. Once it's merged and published,
prqlc's change becomes the same small rename this project already does for its other drivers
(feature name + Cargo.toml version bump + tiberius:: → mssql:: in the test runner).

Security specifics

1. Three unpatched RUSTSEC advisories — RUSTSEC 2026-0098, 2026-0099, 2026-0104
2. Unmerged fixes: prisma/tiberius#419 fixes this yet has been open since 2026-05-12 with no maintainer response.
3. Reachable panics from untrusted server input: #424 and #425 document 11 sites in the TDS decoder where a malformed/malicious server response aborts the client process rather than returning Err. Tracked by the RustSec working group at advisory-db#3148.
4. Maintenance appears stalled: no commits since 2026-03-06, 140 open issues, and a maintainer-handover request (#427) went unanswered for 11 days.

---

Drafted with Claude Code; I reviewed and take responsibility for the content.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HmakCYmBF3qUgiW7ctoFJm

[prql-bot]

Thanks — the dependency-chain analysis checks out against the tree, and the upstream PR is the right sequencing. Three things worth adding.

The advisories are against rustls-webpki, not tiberius. All three (2026-0098, 2026-0099, 2026-0104) name rustls-webpki, reached through tiberius's pin on the rustls 0.21 line. That strengthens the case for the swap rather than weakening it: patched is >= 0.103.12, so there is no 0.101.x release to update to and no lockfile fix for that path — it needs tiberius to move off rustls 0.21, or the crate swapped.

The same three advisories are live on a second path the swap wouldn't clear. libduckdb-sys's build script pulls reqwest 0.12.28 → hyper-rustls 0.27.7 → rustls 0.23.37 → rustls-webpki 0.103.9, which is also below the patched threshold. That one is fixable today, so I've opened #6270 to bump it to 0.103.15 (lockfile-only, three lines).

Scoping, so the priority is clear: tiberius is only reachable under test-dbs-external, which isn't in default = ["cli"] — see the feature block in prqlc/prqlc/Cargo.toml. No published prqlc crate or binary contains it. The reachable-panic concern in points 3 and 4 applies to the integration test runner connecting to a SQL Server container in CI, not to anything a prqlc user runs, which is consistent with the existing note in nightly.yaml that prqlc doesn't cross a trust boundary. So this reads as dependency hygiene rather than user-facing exposure — still worth doing, just not urgent.

Nothing to change here until aljazerzen/connector_arrow#81 merges and publishes; after that the prqlc side is the small rename you describe. Choosing between mssql and tiberius-ng is a maintainer call.

Verification notes

Reverse-dependency edges computed from Cargo.lock at 9f87cd7:

rustls-webpki 0.101.7 <- rustls 0.21.12 <- tokio-rustls 0.24.1 <- tiberius 0.12.3
rustls-webpki 0.103.9 <- rustls 0.23.37  <- tokio-rustls 0.26.4 <- hyper-rustls 0.27.7 <- reqwest 0.12.28 <- libduckdb-sys
tiberius 0.12.3 <- connector_arrow 0.11.0, prqlc 0.13.15

Patched ranges from the advisory-db entries: >= 0.103.12 (0098, 0099) and >= 0.103.13 (0104). 0.101.7 matches neither and has no patched successor on its line.

Direct tiberius use in this repo is confined to prqlc/prqlc/tests/integration/dbs/runner.rs and protocol.rs, matching your read that prqlc only constructs the tiberius::Client it hands to connector_arrow.

cargo audit in nightly.yaml is currently gated off ('run' == 'no'), so these advisories aren't being surfaced by CI — GitHub's Dependabot alerts are the live signal.

A maintainer will weigh in on the crate choice and timing.