c2f063cf47
Instead of keeping around a flag on contexts to know whether we are configured for RPK, we start from SslMethod with a flag to know whether it is configured for X.509 certificates. We then propagate this flag to context builders and contexts, defaulting to false, and introduce `assume_x509` methods to inform the crate of X.509 support for contexts created with other means than our own functions. This improves the safety of the crate as any `SslContextBuilder` configured with `SslMethod::tls_with_buffer` would crash if used with functions involving X.509 certificates. This `SslMethod` is made unsafe because we can't guarantee that we check for X.509 support from all FFI bindingsi (for example, BoringSSL crashes if there is a mismatch in X.509 support in `SSL_set_SSL_CTX`). Note that there is no point anyway in forbidding X.509 functions on a context that supports RPK, as current BoringSSL is able to negociate both raw public keys and X.509 certificates on the same context. Finally, I removed `SslMethod::tls_client` and other peer-specific methods as they are just the same as there non-peer-specific equivalent methods. |
||
|---|---|---|
| .. | ||
| simple-async.rs | ||