Consider reexporting rustls

[Ralith]

rustls ClientConfig and ServerConfig structs are consumed by quinn-proto's public API, but cannot be constructed by a caller without additionally depending upon rustls. This is an ergonomic wart, and could become particularly annoying if a caller needs a different major version of rustls in their crate than ours. Reexporting the crate, and referencing its types directly rather than through the internal crypto facade when they appear in public locations, provides convenient access to exactly the version our interfaces need.

This is contrary to the spirit of our internal efforts to avoid being tightly coupled with rustls, but those efforts aren't currently exposed regardless.

[Ralith]

We also have a ring SigningKey in the EndpointConfig, though that's easier to paper over with a newtype.

[djc]

I'd prefer to just push through to start exposing the traits, I just need to explore the best way to go about it. My main open question is if it's possible to close a type over an internal type parameter.

[Ralith]

I'd prefer to just push through to start exposing the traits

I think we'll still want rustls to Just Work by default at least at the high level API, since TLS is standard QUIC and rustls is by far the most convenient impl. This seems difficult to do without publicly referencing its types, even if only by implementing public traits for them and placing them in default type parameters.

close a type over an internal type parameter

I'm not sure what this is describing; could you provide an example?

[djc]

I think we'll still want rustls to Just Work by default at least at the high level API, since TLS is standard QUIC and rustls is by far the most convenient impl. This seems difficult to do without publicly referencing its types, even if only by implementing public traits for them and placing them in default type parameters.

I wanted to hang this off ClientConfig and ServerConfig types that contain dyn trait impls to kick off CryptoSessions somehow. Seems to me like we can make this ergonomic enough while still allowing users to parametrize with different TLS/crypto implementations.

I'm not sure what this is describing; could you provide an example?

Basically, can we have a ConnectionRef type without type parameters that contains a parametrized Connection type (potentially if we Box the Connection, which might make sense anyway).

[Ralith]

Seems to me like we can make this ergonomic enough while still allowing users to parametrize with different TLS/crypto implementations.

I think this is achievable, I just want to make sure that users will get rustls out of the box if they don't go out of their way for something else.

Basically, can we have a ConnectionRef type without type parameters that contains a parametrized Connection type (potentially if we Box the Connection, which might make sense anyway).

This is generally feasible through trait objects, though it can be a little boilerplatey. I expect the public interface of Connection/Endpoint won't actually expose any genericness aside from the config structs, so if we write a trait that forwards all the method calls and box that it should just work.

[djc]

I now think it makes sense to reexport rustls conditional on the relevant features. I feel like the crypto session provider dependency is fairly fundamental and, although we can try to make the API opaque for simple cases, there's enough moving bits and pieces here that wrapping everything is practically quite hard.

[jonatanzeidler]

Please consider reexporting ClientConfig and ServerConfig from rustls, too. Otherwise one can run into incompatible versions with his own rustls dependency, which happened to me in a project. See this minimal example.

[djc]

@jonatanzeidler want to submit a PR to implement this?

[rageshkrishna]

Running into this with a brand new project that picks uses rustls 0.22. Is there any plan to create a release that includes this fix any time soon?

[djc]

Yes: #1715.

[djc]

See also #1737.