[Fix Native TLS Reqwest] Activate native-tls connector for Entra HTTPS

[ChrisKrawczyk]

[Fix Native TLS Reqwest] Activate native-tls connector for Entra HTTPS

Summary

The Microsoft Entra credential chain in 0.1.31–0.1.32 failed at hyper's connector layer with "invalid URL, scheme is not http" for every HTTPS request — making WorkloadIdentityCredential (AKS / federated identity), ManagedIdentityCredential (HTTPS-bound), and the ClientAssertionCredential token endpoint unreachable. As a result PostgresProvider::new_with_entra / new_with_schema_and_entra could not acquire access tokens in any production topology that did not have the Azure CLI installed locally — passwordless Entra was effectively broken on AKS and similar environments.

Root cause: azure_core 0.35's reqwest feature activates typespec_client_core/reqwest, which activates the optional reqwest dep with default-features = false. With no TLS feature enabled on the resolved reqwest build, hyper rejects every HTTPS URL at the connector layer before any DNS or TCP I/O occurs. The Cargo.toml comment block above the Azure deps claimed the configuration "routes through reqwest's default-tls feature, keeping the build on native-tls" — both halves of that claim are wrong:

1. azure_core/reqwest = ["typespec_client_core/reqwest"] and typespec_client_core/reqwest = ["dep:reqwest"] activate only the optional dep; neither flag enables any reqwest features. typespec_client_core's reqwest dep is default-features = false, suppressing reqwest's own defaults entirely.
2. In reqwest 0.13.3, default-tls = ["rustls"] (the feature was renamed in 0.12→0.13). Even if defaults were active, they would NOT preserve the openssl posture.

tests/entra_live_test.rs only exercises DeveloperToolsCredential (shells out to az login), so the missing TLS in the reqwest transport was never traversed by CI.

Fix

A single line added to [dependencies] in Cargo.toml:

reqwest = { version = "0.13", default-features = false, features = ["native-tls"] }

Cargo's feature unification merges this declaration with typespec_client_core's reqwest dep (same resolved 0.13.3), giving the resolved reqwest crate the ["stream", "native-tls"] feature union. The native-tls feature activates hyper-tls 0.6 and tokio-native-tls 0.3 (openssl-backed on Linux). No source-code changes are required.

The accompanying comment block in Cargo.toml:46-72 is rewritten to describe the actual feature graph and rationale for the explicit dep.

Changes

• Cargo.toml
  • Add explicit reqwest = { version = "0.13", default-features = false, features = ["native-tls"] } to [dependencies].
  • Rewrite the comment block above the Azure deps to reflect the real dep graph (drop the incorrect default-tls claim).
  • Add url = "2" to [dev-dependencies] for the new regression test.
  • Bump package.version from 0.1.32 to 0.1.33.
• tests/native_tls_regression.rs (new)
  • Constructs the HTTP client via azure_core::http::new_http_client(None) — the same constructor azure_identity uses internally — and issues a GET to https://127.0.0.1:1/ (closed local port, fail-fast at TCP-connect, no network egress, no DNS).
  • Asserts the error chain does NOT contain "scheme is not http". That substring is hyper's signature for "no TLS connector compiled in"; its presence indicates the regression has returned.
• CHANGELOG.md
  • Add ## [0.1.33] entry under ### Fixed describing the symptom, root cause, and fix.

Testing

• cargo build --release — clean.
• cargo test --release --test native_tls_regression — 1/1 passes.
• cargo test --release --lib — 35 lib tests pass. 3 provider::entra_pipeline_tests::* fail with "pool timed out while waiting for an open connection" — these require a live Postgres at localhost:5432 and are pre-existing on main, unrelated to this change.
• cargo clippy --all-targets — 0 errors. Only pre-existing warnings (map_identity at src/provider.rs:2913, expect_fun_call in two test files).
• cargo tree --target x86_64-unknown-linux-gnu --edges normal -i rustls / ring / aws-lc-rs / hyper-rustls / tokio-rustls — each returns "did not match any packages". FIPS-compliance posture (no rustls / ring / aws-lc-rs) preserved.
• cargo tree -i hyper-tls — hyper-tls v0.6.0 activated via reqwest v0.13.3 ← duroxide-pg v0.1.33. ✅

Breaking Changes

None. Public API is unchanged; this is a pure dependency-graph fix.

Forward-compatibility note

This fix relies on Cargo's per-crate-version feature unification merging this crate's explicit reqwest 0.13 declaration with typespec_client_core's declaration. If typespec_client_core is ever bumped to declare reqwest at a different major (e.g. 0.14), the two declarations will resolve to different reqwest crates and the fix will silently regress — tests/native_tls_regression.rs is the canary that catches that scenario.

Notes for reviewers

• The fix is one line of Cargo.toml + a comment-block rewrite. No source code is touched.
• The regression test runs entirely offline (no network egress, no Azure credentials) and finishes in ~2 seconds.
• A sibling crate (duroxide-pg-opt) has the same bug and will receive an identical fix in a separate PR.

Artifacts

PAW workflow artifacts (CodeResearch.md, ImplementationPlan.md, Docs.md, WorkflowContext.md) were tracked during development and removed via stop-tracking before this PR. They remain available on the branch at commit 73d369d.

---

🐾 Generated with PAW