Users can override the new default behavior in the usual way. The
expectation is that the build of BoringSSL they provide the feature set
implemented by the patch.
Per BoringSSL's FIPS policy, its `main` branch is the "update branch"
for FedRAMP compliance's purposes.
This means that we can stop using a specific BoringSSL branch when
enabling FIPS, as well as a number of hacks that allowed us to build
more recent BoringSSL versions with an older pre-compiled FIPS modules.
This also required slightly updating the main BoringSSL submodule, as
the previous version had an issue when building with the FIPS option
enabled. This is turn required some changes to the PQ patch as well as
some APIs that don't seem to be exposed publicly, as well as changing
some paths in the other patches.
In order to allow a smooth upgrade of internal projects, the `fips-compat`
feature is reduced in scope and renamed to `legacy-compat-deprecated` so
that we can incrementally upgrade internal BoringSSL forks. In practice
this shouldn't really be something anyone else would need, since in
order to work it requires a specific mix of BoringSSL version and
backported patches.
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.
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.
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.
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
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.
Christopher Patton