Daniel McCarney

Is there any action to take in the Rustls repo for this situation? It seems like there's consensus the problem is with tooling unrelated to Rustls itself.

> they're dependencies that are absolutely required for 99% of uses of the "primary" crate. I think pki-types satisfies that; but not (eg) webpki. Having done a few dependent crate...

I've spent some time thinking about this. Here's my thought process so far. @ctz, @djc does this match your expectations? It seems like [`ClientConnection`](https://github.com/rustls/rustls/blob/582516e241c8330275a2149304c322e4b80baece/rustls/src/client/client_conn.rs#L546-L548) and [`ServerConnection`](https://github.com/rustls/rustls/blob/582516e241c8330275a2149304c322e4b80baece/rustls/src/server/server_conn.rs#L456-L458) should have their [`ConnectionCommon`](https://github.com/rustls/rustls/blob/582516e241c8330275a2149304c322e4b80baece/rustls/src/conn.rs#L347-L352)...

> I think ServerConnection and ClientConnection types should still hold ConnectionCommon because buffered/unbuffered is orthogonal to client/server AIUI. I think we're on the same page here. Agreed for sure that...

I'm still struggling to find a way to make the strategy I described above work with the existing buffered and unbuffered API designs. The biggest issue I'm wrangling right now...

> Is there something obvious I'm missing or is this approach a non-starter? Maybe the updated connection common `write_tls` should call `process_new_packets` itself before trying to write from the adapter's...

Continuing my practice of rubber ducking long comments into this issue. > How about doing process_new_packets inside ClientConnection::new? That would maintain the invariant that a client starts out life with...

> Here's one approach that reduces the number of typestates while preserving the dead-code elimination property (and also the all-or-nothing problem): We could have two entrypoints to make a ConfigBuilder:...

>> ServerConfig::builder_narrowed(protocols, cipher_suites, kx_groups) > > I think the second form would need an additional argument for the &'static dyn CryptoProvider as of https://github.com/rustls/rustls/pull/1448 being in-tree. This also seems like...

That sounds like a good direction to me. :+1: