You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It feels like projects depending on, say, the platform verifier shouldn't have to drag around the provider's signature verification algorithms, even if that means a small ergonomic hit.
✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.29%. Comparing base (3b342b3) to head (4bc6b71). ⚠️ Report is 3 commits behind head on main.
I think this sort of effort should start with rustls-platform-verifier having no dependency on CryptoProvider::signature_verification_algorithms. Currently it uses it on every platform!
I think this sort of effort should start with rustls-platform-verifier having no dependency on CryptoProvider::signature_verification_algorithms. Currently it uses it on every platform!
Ahh, I forgot that verify_server_cert() was just one part of the verifier, and we also have the verify_tls1*_signature() methods which do still end up using the WebPkiSupportedAlgorithms.
So do you think this conceptually makes no sense? It still feels a little weird that rustls itself does not use CryptoProvider::signature_verification_algorithms directly.
I think this sort of effort should start with rustls-platform-verifier having no dependency on CryptoProvider::signature_verification_algorithms. Currently it uses it on every platform!
Ahh, I forgot that verify_server_cert() was just one part of the verifier, and we also have the verify_tls1*_signature() methods which do still end up using the WebPkiSupportedAlgorithms.
So do you think this conceptually makes no sense? It still feels a little weird that rustls itself does not use CryptoProvider::signature_verification_algorithms directly.
In an ideal world there would be a base CryptoProvider and refinements to it (eg, one with HPKE suites for use with ECH, another with signature verification for built-in certificate verification, another with key loading for servers or clients proving their identity, and then all combinations of these). The outcome would be that all CryptoProvider configuration surface would deal with all of these, and the API for (eg) ECH would become unavailable if your configured provider can't do that, and nobody would have to deal with a fragmented set of items like in this PR.
However, I don't know how to actually do that without creating a system of multi-dimension generic types that would make a libboost maintainer go "ehh, steady on!"
However, I don't know how to actually do that without creating a system of multi-dimension generic types that would make a libboost maintainer go "ehh, steady on!"
I'll take that as a challenge! What if CryptoProvider becomes a trait and we have various subtraits? ServerConfig and ClientConfig both take a <P> for their provider and a P: CryptoProvider can additionally be QuicProvider or HpkeProvider. Doesn't seem all that multidimensional?
I guess the multidimensional part would be someone wanting to do quic+client auth+default server verifier? So they would have to find/construct a type that impl CryptoProvider + QuicProvider + AuthProvider + VerifierProvider or whatever
Sure, but I would argue that's additive and so only constitutes a single dimension? It doesn't seem very onerous, particularly if it's mostly just AwsLcRsProvider providing a bunch of stuff, the Ring provider providing less stuff, etc.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What do we think of doing something like this?
It feels like projects depending on, say, the platform verifier shouldn't have to drag around the provider's signature verification algorithms, even if that means a small ergonomic hit.