This means BORING_SSL_PRECOMPILED_BCM_O is now
BORING_BSSL_PRECOMPILED_BCM_O.
Prefix BORING_BSSL_ has been chosen because that's the
one that is used the most among all the variables
the build script uses.
In boringssl, FIPS_mode_set is more or less useless, and
it doesn't even set an error stack at all on failure,
so there is no point using it instead of FIPS_mode.
To handle lifetimes better and allow returning a &mut SslRef from
the client hello struct passed to the closure from
SslContextBuilder::set_select_certificate_callback, we make
the ClientHello struct itself own a reference to the FFI
client hello struct.
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