Upgrade to rustls 0.23 #3399
Upgrade to rustls 0.23 #3399
Conversation
djc
force-pushed
the
rustls-0.23
branch
2 times, most recently
from
22a380a to
8351d62
Compare
djc
force-pushed
the
rustls-0.23
branch
3 times, most recently
from
8de5060 to
048e04c
Compare
|
Feels like the test matrix gets fairly extreme. IMO it doesn't really make sense to test the matrix of TLS implementations (x crypto providers) against all database versions, but that's sort of orthogonal. |
|
It is rather important, because it's caught incompatibilities that have crept in upstream: #3091 |
|
Oh, I could absolutely see testing recent versions of the databases against all TLS stacks (and potentially crypto providers), just not sure it's all that valuable to do this against the entire back catalog of database versions. |
|
It's not the entire back catalog, the policy is the oldest and newest actively supported versions. MariaDB is a bit of a special case because we added the If there are any versions that don't fit with this policy, it's just because the file hasn't been updated. As for testing Ring vs I don't care as much anymore about the number of CI passes as I used to. I'm perfectly happy to let Micro$oft foot the bill. |
|
Crypto providers might definitely have different cipher suites. |
There was a problem hiding this comment.
Can you add a note about crypto providers to https://github.com/launchbadge/sqlx/blob/main/src/lib.md#tls-support?
Done. |
Upgrade rustls to 0.23.x. The tricky part here is that rustls since 0.22 exposes two
CryptoProviderimplementations here. So far I've exposed separate features for each, but this still runs the risk that a project that ends up with crates selecting rustls with different crypto providers picks an unexpected one. I guess there's not much of a solution for that, but open to feedback about what you think the right direction is for sqlx.