fix(security): upgrade rustls stack to 0.23 — clear RUSTSEC-2026-0098/-0099/-0104 - #439
fix(security): upgrade rustls stack to 0.23 — clear RUSTSEC-2026-0098/-0099/-0104#439MattJackson wants to merge 2 commits into
Conversation
MattJackson
changed the title
SimSmith
left a comment
SimSmith
left a comment
There was a problem hiding this comment.
I took a quick look on the go and consulted with GPT: https://chatgpt.com/share/6a985539-a350-83ed-b73f-dadb32415ae3
|
|
||
| let builder = ClientConfig::builder().with_safe_defaults(); | ||
| let builder = ClientConfig::builder_with_provider(Arc::new(aws_lc_rs::default_provider())) | ||
| .with_protocol_versions(&[&version::TLS12]) |
There was a problem hiding this comment.
Isn't this pinning it to 1.2 only. Meaning 1.3 is not supported anymore? That's a downgrade.
There was a problem hiding this comment.
Good catch, thanks. You're right, this was negotiating TLS 1.2 only — it crept in during the rustls 0.21→0.23 migration, where with_safe_defaults() (1.2 and 1.3) was replaced with an explicit with_protocol_versions(&[TLS12]); there was no reason to cap it. Fixed here: it now uses with_safe_default_protocol_versions(), so it negotiates 1.3 when available and falls back to 1.2 for older servers. Verified against SQL Server 2022.
|
|
||
| [dependencies.rustls-pemfile] | ||
| version = "1" | ||
| version = "0.26" |
There was a problem hiding this comment.
This pulls in rustls-webpki but the security patched 0.103.13 version is not required here (https://rustsec.org/advisories/RUSTSEC-2026-0104.html). A user might accidentally pull in 0.103.12, for example.
There was a problem hiding this comment.
Good point. rustls-webpki was only transitive here (via tokio-rustls), so nothing held the floor at the RUSTSEC-2026-0104 fix and a downstream resolve could pick <0.103.13. Addressed: bumped the tokio-rustls floor and added an explicit rustls-webpki = ">=0.103.13" (gated behind the rustls feature) so the patched version can't be resolved away. Thanks!
| event!(Level::INFO, "Performing a TLS handshake"); | ||
|
|
||
| let builder = ClientConfig::builder().with_safe_defaults(); | ||
| let builder = ClientConfig::builder_with_provider(Arc::new(aws_lc_rs::default_provider())) |
There was a problem hiding this comment.
This always construct with aws_lc_rs as a crypto provider. Consider allowing an application to install their own and get
CryptoProvider::get_default() if it exist. Otherwise fallback to aws_lc_rs as the default.
There was a problem hiding this comment.
Good suggestion, thanks @SimSmith — agreed it's better to honor a process-installed CryptoProvider::get_default() and fall back to aws-lc-rs only as the default, so apps using ring/a FIPS provider aren't forced onto aws-lc-rs.
I'd like to keep this PR scoped to the security fix (clearing the rustls CVEs, mirroring @jakewimmer's #419) so it can land as a clean patch, and do the crypto-provider flexibility as a small focused follow-up. I'll track it separately so it isn't lost.
There was a problem hiding this comment.
Update: implemented — it now honors CryptoProvider::get_default() and falls back to aws-lc-rs. It's in the stack as #446. Thanks again for the suggestion.
73ae7a2 to
670434f
Compare
670434f to
8de5bab
Compare
Upgrade tokio-rustls to 0.26, rustls to 0.23, and rustls-native-certs to 0.8 to resolve RUSTSEC-2024-0421 and RUSTSEC-2025-0010. Migrate the TLS stream to the rustls 0.23 API. Switch the crypto provider to aws-lc-rs via builder_with_provider to avoid the dual-provider conflict that tokio-rustls 0.26 introduces when ring is also in the dependency graph. Pin to TLS 1.2 to prevent TLS 1.3 KeyUpdate messages from triggering UnexpectedEof on the macOS CI runner. (cherry picked from commit d46e4c0)
azure_core 0.20.0 switched from reqwest 0.11 to reqwest 0.12, which pulls in rustls 0.23 and rustls-webpki 0.103.13. Bumping azure_identity to 0.20.0 closes RUSTSEC-2026-0098, 0099, and 0104 in the dev build without any changes to the production stack. client_credentials_flow::perform now takes &str for the client secret. Updated aad-auth.rs to pass raw env var strings and dropped the oauth2 ClientId/ClientSecret wrappers. Also bump reqwest 0.11 -> 0.12 and oauth2 4.2.3 -> 5.0 in dev-dependencies to match. Remove .cargo/audit.toml - the suppressions are no longer needed. (cherry picked from commit 0e90db7)
8de5bab to
c90fead
Compare
|
all 8 stacks are now green thank you to everyone for all the suggestions, if anything else comes up ill fix and adjust |
3 participants
Resolves the three rustls certificate-verification advisories. Both commits are @jakewimmer's work (mirrors #419), authorship preserved.
tokio-rustls0.24→0.26 (rustls 0.21→0.23),rustls-native-certs0.6→0.8 → pulls inrustls-webpki0.103.x.ServerCertVerifier(verify_tls13_signature,supported_verify_schemes),Certificate→CertificateDer,aws-lc-rscrypto provider; TLS-only items gated so--no-default-featuresbuilds stay clean.azure_identity0.5.0→0.20.0 (aad-auth example).Non-breaking — no public API changes. Safe for a patch release, no major bump. Verified: builds clean (default / rustls /
--features all),cargo auditconfirms RUSTSEC-2026-0098/-0099/-0104 cleared.Supersedes #419 — same fix, credit to @jakewimmer.
Out of scope (separate follow-up):
azure_core(RUSTSEC-2026-0275, dev-dep) andrkyv(RUSTSEC-2026-0235, transitive under optionalrust_decimal).Reviewer note: please rebase-merge or merge-commit, not squash — this PR carries @jakewimmer's commits with authorship intact; squashing would collapse that credit.