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".
* RTG-3333 Support X25519MLKEM768 by default, but don't sent it as client
X25519MLKEM768 is the standardised successor of the preliminary
X25519Kyber768Draft00. Latest browsers have switched to X25519MLKEM768.
Cloudflare supports both on the edge.
We've had support for X25519MLKEM768 in this crate for a while, but
didn't enable by default. We're now enabling serverside support by
default. We also let clients advertise support when set
to kx-client-pq-supported.
We don't enable support by default yet for clients set to
kx-client-pq-preferred, as that would cause an extra round-trip due to
HelloRetryRequest if the server doesn't support X25519MLKEM768 yet.
BoringSSL against which we build must support X25519MLKEM768, otherwise
this will fail.
* replace once_cell with LazyLock
We can drop the once_cell dependency since the same functionality is
implemented in std now.
Requires bumping MSRV to 1.80.
* fix manual_c_str_literals clippy warning
* chore: Fix docs on SslRef::replace_ex_data
* Detailed error codes
* Clean up boring_sys::init()
We don't need the workaround that was initially introduced for a bug in
openssl, and OPENSSL_init_ssl always calls into CRYPTO_library_init on
boringssl, so just call it explicitly.
* Expose EVP_HPKE_KEY
* Expose client/server-side ECH
Resolves https://github.com/cloudflare/boring/issues/282
* Clean up ECH tests
* Expose SSL_set_enable_ech_grease
* Use corresponds macro
* build: Fix the build for 32-bit Linux platform (#312)
build: Fix the build for 32-bit Linux platform
* Set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism
cmake-rs' jobserver doesn't work reliably, if at all. One workaround is
to set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism(). On my
machine it shaves ~35 seconds off of boring-sys builds.
* Expose SSL_CTX_set1_ech_keys from SslContextRef
We currently expose this method on `SslContextBuilder`, which is fine
for bootstrapping an `SSL_CTX`, but subsequent attempts to set ECH keys
(like during key rotation) can only happen via `SslContextRef`. Also
update the method on the builder to take an immutable reference to self
because the API is thread safe.
* Bump cmake-rs to improve Mac OS build parallelism
There's a bug on OSX that prevents the CMake jobserver from working
properly, and so CMake defaults to a single-threaded build. It's not
clear when this is actually going to get fixed, so recent versions of
cmake-rs just disable the jobserver and have CMake fall back to the
number of available cores:
https://github.com/rust-lang/cmake-rs/pull/229
This means we don't need e6833b0074
* Release 4.14.0 (#317)
* Actually expose SslEchKeys
* Address clippy lints
* Revert "Refactor!: Introduce a Cargo feature for optional Hyper 0 support"
This reverts commit 49d5a61163.
* Revert "Refactor!: Remove strict `TokioIo` response requirement from `hyper_boring::v1::HttpsConnector`"
This reverts commit e518c2444a.
* Introduce a builder pattern for SslEchKeys + make set_ech_keys take a reference (#320)
Previously, set_ech_keys would consume the SslEchKeys struct to enforce
the requirement that the struct is immutable after initializing it on a
SSL_CTX. The problem with this is that it requires applications to
needlessly reallocate the SslEchKeys struct if they want to initialize
keys on multiple SSL_CTXs, which is a pretty common pattern. To work
around this, we introduce a builder (SslEchKeysBuilder) that requires
mutable access to add keys to the underlying struct. set_ech_keys takes
in a reference to SslEchKeys, which can only be made via consuming the
builder.
* Revert cmake bump (for now) as it is overly restrictive (#321)
Some users of boring have issues with newer versions of cmake. Because
we have an alternative solution, we can hold off on the bump for now.
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: Kornel <kornel@cloudflare.com>
Co-authored-by: Rushil Mehra <rmehra@cloudflare.com>
Co-authored-by: Rushil Mehra <84047965+rushilmehra@users.noreply.github.com>
There's a bug on OSX that prevents the CMake jobserver from working
properly, and so CMake defaults to a single-threaded build. It's not
clear when this is actually going to get fixed, so recent versions of
cmake-rs just disable the jobserver and have CMake fall back to the
number of available cores:
https://github.com/rust-lang/cmake-rs/pull/229
This means we don't need e6833b0074
cmake-rs' jobserver doesn't work reliably, if at all. One workaround is
to set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism(). On my
machine it shaves ~35 seconds off of boring-sys builds.
As of https://boringssl-review.googlesource.com/c/boringssl/+/66288,
libssl allows a C++ runtime dependency. As such, we need to link with a
cpp runtime library. Implementation is inspired heavily from
54c956b2e6.
Before releasing this change, we'll need to figure out a way to support
this for windows.
* Release 4.10.3 (#280)
* Create semgrep.yml
Creating Semgrep.yml file - Semgrep is a tool that will be used to scan Cloudflare's public repos for Supply chain, code and secrets. This work is part of Application & Product Security team's initiative to onboard Semgrep onto all of Cloudflare's public repos.
In case of any questions, please reach out to "Hrushikesh Deshpande" on cf internal chat.
* Add "fips-compat" feature (#286)
This adds a feature to build against a BoringSSL version compatible with
the current boringssl-fips, but _without_ actually enabling the `fips`
feature.
This can be useful to use with `fips-link-precompiled` while using a
custom BoringSSL version based on the older FIPS branch.
* boring-sys: include HPKE header file for bindgen
BoringSSL doesn't expose these APIs for FIPs builds, so we gate them
here as well
* Release 4.11.0
* Add `set_cert_verify_callback` (`SSL_CTX_set_cert_verify`)
Add a wrapper for `SSL_CTX_set_cert_verify`, which allows consumers to
override the default certificate verification behavior.
The binding resembles `SSL_CTX_set_verify`'s.
See
https://docs.openssl.org/master/man3/SSL_CTX_set_cert_verify_callback/
for more details.
* Skip bindgen 0.70's layout tests before Rust 1.77
* (ci): brew link x86 toolchain for macos13 runner
It seems we need to manually symlink the x86_64-unknown-linux-gnu
toolchain for the macos13 runner. Also, we don't need to overwrite the
python version anymore
Fixes https://github.com/cloudflare/boring/issues/285
* feat(boring): Add SSL_CURVE_X25519_MLKEM768 curve binding
---------
Co-authored-by: Rushil Mehra <84047965+rushilmehra@users.noreply.github.com>
Co-authored-by: Hrushikesh Deshpande <161167942+hrushikeshdeshpande@users.noreply.github.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: James Larisch <jlarisch@cloudflare.com>
Co-authored-by: Jordan Rose <jrose@signal.org>
Co-authored-by: Rushil Mehra <rmehra@cloudflare.com>
With the bindgen 0.70 upgrade, the default rust target is set to be 1.77,
which becomes the de facto MSRV of boring-sys since the change.
This change makes sure that the MSRV of boring-sys is kept at 1.70,
which is the same as that of bindgen.
When passing BORING_BSSL_FIPS_PATH, you need to add /lib/ to the search
path, and when passing BORING_BSSL_PATH you need to add /crypto/ and
/ssl/ to the search path.
We need to add `/build/crypto` and `/build/ssl` to the library search
path to handle the case where we pass `BORING_BSSL_SOURCE_PATH` when
building without enabling any fips features. Otherwise, non bazel
commits will not work because `/build/` itself will not contain any
crypto libraries to link with
These variables let us configure CMAKE_SYSROOT and
CMAKE_{C,CXX,ASM}_EXTERNAL_TOOLCHAIN from env variables
without needing an error-prone custom toolchain file.
Most users won't need BORING_BSSL_EXTERNAL_TOOLCHAIN, but some
packages (such as Homebrew package
messense/macos-cross-toolchains/x86_64-unknown-linux-gnu) don't
install the sysroot at the root of the GCC installation, so clang-12
cannot find crt1.o and crti.o.
Finally, we also set up CMAKE_CROSSCOMPILING and
CMAKE_{C,CXX,ASM}_COMPILER_TARGET to make cross compilation work
with compilers that have cross-compiling drivers (i.e. clang).
We can now cross build boring-sys from macOS to Linux with
fips feature turned on:
brew tap nox/misc
brew install llvm@12.0.0
export PATH="$(brew --prefix llvm@12.0.0)/bin:$PATH"
brew tap messense/macos-cross-toolchains
brew install x86_64-unknown-linux-gnu
export BORING_BSSL_FIPS_EXTERNAL_TOOLCHAIN="$(brew --prefix x86_64-unknown-linux-gnu)/toolchain"
export BORING_BSSL_FIPS_SYSROOT="$BORING_BSSL_FIPS_EXTERNAL_TOOLCHAIN/x86_unknown-linux-gnu/sysroot"
cargo build --target x86_64-unknown-linux-gnu -p boring-sys --features fips
The logic is stolen from cmake-rs, and it is important to
follow it as we will need to look for CMAKE_TOOLCHAIN_FILE
the same way cmake-rs does.
When checking for env variable BORING_BSSL_PATH during a
cross build for target x86_64-unknown-linux-gnu, boring-sys
build script will attempt to read:
BORING_BSSL_PATH_x86_64-unknown-linux-gnu
BORING_BSSL_PATH_x86_64_unknown_linux_gnu
TARGET_BORING_BSSL_PATH
BORING_BSSL_PATH
A basic LLVM 12 build provides clang-12 but not clang++-12, but
it does provide both clang and clang++, so we shouldn't hard fail
when first checking for clang-12 and clang++-12.
Feature no-patches is ever only useful when setting other env variables
BORING_BSSL{,_FIPS}{,_SOURCE}_PATH, and it has no impact on the APIs
provided by any of the boring crates, so we may as well make it an env
variable itself so downstream users have less features to propagate
across their own crate graph.
Builds using feature fips or fips-link-precompiled now
read variables prefixed by BORING_BSSL_FIPS_ instead of
BORING_BSSL_. This helps complex builds where build dependencies
also use boring, where we may not want to use fips there.
Without those separate variables, the boring build for the
build dependencies end up relying on e.g. BORING_BSSL_PATH,
causing errors if this path is a boring checkout intended for
fips builds, while the fips feature isn't enabled for
the build dependency.
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.
Using a struct improves navigation of the build script,
as we can rely on rust-analyzer to help us check how
a feature flag or an environment variable is used,
as opposed to grepping for multiple env::var calls
or #[cfg] attributes.
This commit also removes some obsolete blocks of code
related to the now defunct ndk-old-gcc and fuzzing features.
0x676e67