feat(tls): support application-selected rustls crypto providers

[juanjosalco]

Follow-up to #446: honoring a process-installed CryptoProvider does not let applications avoid compiling AWS-LC while tokio-rustls enables its defaults and Tiberius has an unconditional AWS-LC fallback.

Change

• Add rustls-no-provider, enabling the existing Rustls implementation without a crypto backend.
• Disable tokio-rustls defaults, explicitly retain logging/TLS 1.2, and make the existing rustls feature forward AWS-LC. Its installed-provider preference and connection-local fallback remain unchanged.
• In provider-neutral mode, require a process-installed Rustls 0.23 CryptoProvider; missing providers produce an actionable Error::Tls, not a panic or backend inference.
• Move TLS availability guards to the common feature so configuration, client certificates, prelogin/TDS 8.0, and error conversion remain available. Most changed source files contain only this mechanical guard update.
• Leave certificate/hostname verification, CA loading, native TLS, release version, and the declared Rust 1.88 minimum unchanged.

Consumer configuration: default-features = false, features = ["tds73", "rustls-no-provider"]; install the application's provider once before Client::connect. Use tds80 instead of tds73 for strict encryption.

Cargo features are additive. rustls-webpki-roots still implies rustls and AWS-LC for compatibility; provider-neutral users can use native roots and additional CA files/bundles instead. No provider-neutral bundled-root feature is introduced here.

Regression coverage

The isolated consumer under tests/rustls-provider has its own workspace, so root dev-dependencies cannot mask a backend leak. Separate integration binaries isolate process-global provider state.

• Missing provider fails on strict, required, and login-only (Off) TLS paths, even when a provider backend was compiled but not installed.
• Installed provider policy actually determines negotiated TLS 1.2 and TLS 1.3 cipher suites in verified, in-memory handshakes; TDS 8.0 ALPN and transition to prelogin are checked.
• Legacy rustls works without installation and does not mutate the process default.
• CI checks the provider-neutral normal dependency graph, the isolated consumer with no provider/Ring/AWS-LC/OpenSSL, and the existing library TLS suites.
• The Rust 1.88 MSRV job now also runs cargo check --no-default-features --features rustls-no-provider,tds80 --lib immediately after its unchanged cargo check --features all step. The adjacent comment distinguishes the native-TLS all feature, provider-neutral MSRV coverage, and stable Rustls backend tests.

Validation

The following implementation results were recorded at 8bbd59fe9e01a74b6f790756077c8b0e09605c68; they were not rerun for the CI-only follow-up below. All listed configurations passed locally on x86_64:

Configuration	Windows	Linux
Provider-neutral library unit tests	1026	1017
Legacy Rustls library unit tests	1027	1018
Rustls bundled-root library unit tests	1033	1024
Default/native-TLS library unit tests	978	969
Isolated consumer, no provider	Passed	Passed
Isolated consumer, Ring	Passed	Passed
Isolated consumer, AWS-LC	Passed	Passed
Isolated consumer, OpenSSL provider	Not run	Passed
Isolated consumer, SymCrypt provider	Passed	Not run

Windows library Rustls tests include winauth because existing Windows authentication unit tests need it; the isolated provider consumers do not. SymCrypt used rustls-symcrypt 0.2.3 and a session-local SymCrypt 103.13.0 SDK/runtime. Linux OpenSSL used rustls-openssl 0.4.2 with system OpenSSL 3.5.1.

Normal dependency graph results:

• Provider-neutral: no Ring, AWS-LC, OpenSSL, or SymCrypt backend.
• Ring selection: only Ring 0.17.14.
• OpenSSL selection: only OpenSSL 0.10.81 / openssl-sys 0.9.117.
• SymCrypt selection: only symcrypt 0.5.1 / symcrypt-sys 0.4.0.
• No AWS-LC in any of the alternate-provider graphs.

cargo fmt --check (both workspaces), git diff --check, advisory Clippy, Rustdoc, and no-TLS / provider-neutral TDS feature compilation also passed. Existing Clippy/Rustdoc warnings remain outside this patch.

No live database was required. This is not a full platform matrix: macOS, ARM, and the separate vendored-OpenSSL TLS backend were not exercised.

Rust 1.88 CI follow-up

CI-only commit: 773dca9282e68dd84dac44481bf5a2bcc844512e. Only .github/workflows/test.yml changed; no library, dependency-manifest, release-version, or MSRV changes.

Exact command, run on Windows x86_64 (x86_64-pc-windows-msvc) using rustc 1.88.0 (6b00bc388 2025-06-23) and cargo 1.88.0 (873a06493 2025-05-10):

cargo +1.88.0 check --no-default-features --features rustls-no-provider,tds80 --lib

• Existing lockfile and fresh dependency resolution: failed (exit 101). Both select uuid 1.27.0, which requires Rust 1.89.0. This comes from the existing uuid = "1.0" dependency, not the provider-neutral changes.
• Diagnostic compatible resolution: passed (exit 0). After cargo +1.88.0 update -p uuid --precise 1.26.0 changed only the ignored local lockfile, the exact check above completed successfully with six existing Windows dead-code warnings. The original ignored lockfile was restored afterward; no dependency pin was committed.

This establishes that the provider-neutral code compiles on Rust 1.88 with compatible dependencies, not that an unconstrained fresh MSRV build is green. The UUID resolution issue remains unresolved and needs a separately agreed dependency/resolution policy; this surgical CI follow-up does not hide it or raise the MSRV.

Both workspace cargo fmt --check commands and git diff --check passed. PyYAML parsed the workflow and a structural comparison confirmed that the sole behavioral change is the requested step, immediately after the existing MSRV check, with toolchain 1.88 unchanged. No full feature matrix or database tests were rerun for this CI-only change.

At the pushed follow-up head, Cargo tests, PR Code Security, and Security audit report action_required with zero check runs, consistent with pending maintainer approval for fork workflows. This is not a test failure or successful CI execution.

Implementation commit: 8bbd59fe9e01a74b6f790756077c8b0e09605c68, based on upstream main 35605c90adb38cc107d35c3432fd2643d9d6e1e6. Current head adds the CI-only follow-up 773dca9282e68dd84dac44481bf5a2bcc844512e.

Closes #457

[juanjosalco]

I’ve linked an issue describing the use case and proposed behavior. This keeps the existing rustls behavior unchanged while allowing applications to avoid an unused AWS-LC dependency. Does this approach look reasonable? The workflows appear to be awaiting approval; could a maintainer approve them when convenient?