As X509_STORE_CTX_init requires its arguments to outlive
the store context, we take ownership of all of them
and put them in the store context's ex data, ensuring
the soundness of the operation without the mandatory
call to X509_STORE_CTX_cleanup after a closure
is run.
As X509_STORE_CTX_init may fail after setting some values
that should outlive the store context, we must ensure we
clean things up on its error path too.
We also know it's always ok to call X509_STORE_CTX_cleanupas X509_STORE_CTX_init starts with a call to it.
* Revert "feat(x509): Implement `Clone` for `X509Store` (#339)"
This reverts commit 49a8d0906a.
See <https://github.com/cloudflare/boring/pull/120>.
* Ensure Clone is not added to X509Store
* Add comment about why X509Store must not implement Clone
---------
Co-authored-by: Kornel <kornel@cloudflare.com>
This method reliably retrieves the certificate the `X509_STORE_CTX` is
verifying, unlike `X509_STORE_CTX_get_current_cert`, which may return
the "problematic" cert when verification fails.
Newer versions of FIPS don't need any special casing in our bindings,
unlike the submoduled boringssl-fips. In addition, many users currently
use FIPS by precompiling BoringSSL with the proper build tools and
passing that in to the bindings.
Until we adopt the Update Stream pattern for FIPS, there are two main
use cases:
1. Passing an unmodified, precompiled FIPS validated version of
boringssl (fips-precompiled)
2. Passing a custom source directory of boringssl meant to be linked
with a FIPS validated bcm.o. This is mainly useful if you carry
custom patches but still want to use a FIPS validated BoringCrypto.
(fips-link-precompiled)
This commit introduces the `fips-precompiled` feature and removes the
`fips-no-compat` feature.
The "fips" feature implies use of a prebuilt boringSSL. The boringSSL
API consumed by `SslCurve` in incompatible with older versions of
boringSSL.
In the `ffi` bindings, the following symbols don't exist in older
builds:
* NID_X25519MLKEM768
* SSL_CURVE_X25519_MLKEM768
* NID_X25519Kyber768Draft00Old
The following symbols have been renamed:
* SSL_CURVE_P256KYBER768DRAFT00 => SSL_CURVE_P256_KYBER768_DRAFT00
* SSL_CURVE_X25519KYBER512DRAFT00 => SSL_CURVE_X25519_KYBER512_DRAFT00
* SSL_CURVE_X25519KYBER768DRAFT00OLD => SSL_CURVE_X25519_KYBER768_DRAFT00_OLD
* SSL_CURVE_P256KYBER768DRAFT00 => SSL_CURVE_P256_KYBER768_DRAFT00
Meanwhile, the `ssl_set_curves_list()` API is stable across these
versions of boringSSL.
These codepoints are added to the `SslCurve` API whenever
"pq-experimental" is enabled. Since this feature is no longer mutually
exclusive with prebuilt boringSSL (`boring-sys` just ignores patches),
we also need to disable this API whenever "fips" is enabled.
Internal users often have two builds for `boring`, one using a
precompiled build of boringSSL and another built from source with
patches applied. However the features that enable these builds are
mutually exclusive. For example, the `"pq-experimental"` feature is
required to build the source with all of the necessary codepoints for PQ
key exchange, but if this feature is enabled and a precompiled boringSSL
is provided, then the build will fail. This means users will have to
also control their builds with mutually exclusive features.
An alternative is to *ignore* features that enable patches whenever a
precompiled boringSSL is provided. This is a little different from the
"assume patched" environment variable, which applies whenever we're
building from source.
Modify the "fips" feature so that it no longer implies "fips-compat".
The latter is no longer needed for recent builds of boringSSL; users who
need older builds will need to enable "fips-compat" explicitly.
Also, remove the "fipps-no-compat" feature, as it's now equivalent to
"fips".
As of boringSSL commit a430310d6563c0734ddafca7731570dfb683dc19, we no
longer need to make exceptions for the types of BufLen, ProtosLen, and
ValueLen, which means the "fips-compat" feature is no longer needed for
"fips" users.
Currently "fips" implies "fips-compat". To allow users to upgrade
without breaking API compatibility with boring version 4, add a new
feature, "fips-no-compat", that does not imply "fips-compat".
In boring 5, we should remove "fips-no-compat" and decouple
"fips-compat" from "fips".
This algorithm is advertised with "kx-client-pq-supported" but not with
"preferred". However the algorithm is wide spread enough that preferring
it is not a significant risk.
v4.15.0 was tagged a few days ago but wasn't released until today, where
a new commit made it to master and snuck into the publish. I updated the
v4.15.0 tag to point to the right commit hash as well.
See https://github.com/sfackler/rust-openssl/pull/2360 and
https://nvd.nist.gov/vuln/detail/CVE-2025-24898. From the rust-openssl
PR:
`SSL_select_next_proto` can return a pointer into either the client or
server buffers, but the type signature of the function previously only
bound the output buffer to the client buffer. This can result in a UAF
in situations where the server slice does not point to a long-lived
allocation.
Thanks to Matt Mastracci for reporting this issue.
Kornel