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.
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.
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.
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.
Fix three potential timing sidechannels. These don't affect ephemeral
usage of Kyber as in TLS, but it's good practice to get rid of them anyway.
Also adds IPDWing, a preliminary version of X-Wing using the initial public
draft (IPD) of ML-KEM. Don't use it.
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.
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 commit modifies the Cargo `include` field for `boring-sys` to
include all the files necessary to actually build the FIPS-certified
revision of BoringSSL. Currently, some of these files are missing (see
#157 for details on this).
This branch improves on my previous approach in PR #158, which switched
from using a Cargo `include` to a Cargo `exclude`. Using `exclude`
rather than `include` resulted in a much larger crates.io package, but
at the time, I thought this was less likely to result in breakage in the
future, because I was concerned about the inability to verify that the
set of excludes/includes can build a new pinned `boringssl` git revision
without having to actually publish a crates.io release.
However, as @nox pointed out in [this comment][1], `cargo package` can
be used to verify a build with the `exclude`s/`include`s applied. This
branch therefore adds `cargo package` steps to CI that check that the
package can actually be built. This way, we are able to make a much
smaller change to the included files, resulting in a smaller package
published to crates.io.
On this branch, the package is 6.7MiB compressed, which is not much
larger than it was previously:
```
Finished dev [unoptimized + debuginfo] target(s) in 55.65s
Packaged 1851 files, 33.7MiB (6.7MiB compressed)
```
Fixes#157Closes#158
[1]: https://github.com/cloudflare/boring/pull/158#issuecomment-1693067112,
Rushil Mehra