These two new kinds of methods immediately return a MidHandshakeSslStream
instead of actually initiating a handshake. This greatly simplifies
loops around MidHandshakeSslStream::WouldBlock.
Overwrite boringSSL's default key exchange preferences with safe
defaults using feature flags:
* "kx-pq-supported" enables support for PQ key exchange algorithms.
Classical key exchange is still preferred, but will be upgraded to PQ
if requested.
* "kx-pq-preferred" enables preference for PQ key exchange,
with fallback to classical key exchange if requested.
* "kx-nist-required" disables non-NIST key exchange.
Each feature implies "kx-safe-default". When this feature is enabled,
don't compile bindings for `SSL_CTX_set1_curves()` and `SslCurve`. This
is to prevent the feature flags from silently overriding curve
preferences chosen by the user.
Ideally we'd allow both: that is, use "kx-*" to set defaults, but still
allow the user to manually override them. However, this doesn't work
because by the time the `SSL_CTX` is constructed, we don't yet know
whether we're the client or server. (The "kx-*" features set different
preferences for each.) If "kx-sfe-default" is set, then the curve
preferences are set just before initiating a TLS handshake
(`SslStreamBuilder::connect()`) or waiting for a TLS handshake
(`SslStreamBuilder::accept()`).
This reverts commit 1c1af4b38b, reversing
changes made to da32be1fa9.
SslContextBuilder::cert_store_mut returns a &mut X509StoreBuilder
backed by a X509Store that is already shared with an existing SslContext.
Since X509Name is more complex than a single value (it's a a sequence
of entries) it's useful to be able to serialise/deserialise to/from
flat data, and DER is a natural form for this.
So add a {i2d,d2i}_X509_NAME -sys functions, and to_der/from_der
wrappers in X509NameRef and X509Name respectively.
Originally added in https://github.com/sfackler/rust-openssl/pull/1534
According to [the docs](https://doc.rust-lang.org/stable/std/mem/fn.uninitialized.html),
> Calling this when the content is not yet fully initialized causes immediate undefined behavior.
> it [is] undefined behavior to have uninitialized data in a variable even if that variable has an integer type.
Using MaybeUninit instead, as recommended by the official documentation, avoids undefined behavior by not creating a `&mut` reference to uninitialized data.
Alessandro Ghedini