Jacob Hoffman-Andrews

The ClientHelloReader wound up as Acceptor in the rustls API. We have an open ticket here to implement it in rustls: https://github.com/rustls/rustls-ffi/issues/155. For mod_tls you should probably wait for that...

One problem I see is that our Makefile builds `client` and `server` by default when you run `make`, but those are part of the tests, so you shouldn't need to...

> (Was this meant to be filed on [rustls/rustls-ffi](https://github.com/rustls/rustls-ffi) instead of this repo?) Yep, thanks!

> Is this CRYPTO_PROVIDER Makefile arg roughly what you had in mind for selecting the crate features + provider options at build time? Yes, this is good. > rustls_connection_get_negotiated_ciphersuite uses...

> That type \[rustls_supported_cipher_suite\] is also used for the rustls_{client|server}_config_builder_new_custom cipher_suites argument. Oops, you are correct. Okay, an amendment: When calling `get_negotiated_ciphersuite`, the user only cares about the configuration aspect...

Generally looks right. `rustls_certified_key_build_with_provider` isn't a match for the Rust API of [`CertifiedKey`](https://docs.rs/rustls/latest/rustls/sign/struct.CertifiedKey.html). The C function takes a whole crypto provider, when `CertifiedKey::new` just takes an `Arc`. To match the...

I'm in favor of crustls implementing client certificates to the extent that rustls does. But if there's work still to be done on the rustls side to make them reach...

This is great! Also worth mentioning that work is underway in `rustls` to allow pluggable crypto backends. That would let us sub in a pure-Rust crypto backend, which in turn...

Thanks for the suggestion! I definitely agree we can trust the type system. I use abundant type annotations to make comprehension easier for the future reader. For instance, consider this...

I still feel pretty strongly that explicit type annotations, used judiciously, are a great benefit to readability, particularly when types are an important part of understanding why a piece of...