This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Also stick the very verbose default install directory in a variable so
we don't have to repeat it everywhere.
Change-Id: I1a6a85c4d42d3a6e766e52b2d0ecd8e81c6ed4e3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56607
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Slowly reduce clutter in the top-level CMake file.
Change-Id: Ib7ca2aee7337db82ed1989c56bbaaf6ee5da0768
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56569
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Looks like this has since been fixed (or isn't hitting GTest anymore for
some reason).
Bug: chromium:772117
Change-Id: I2c2fb694e4429281e20fd252ef9c2c34e29a425c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56570
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
test_support_lib depends on GTest and should be marked as such.
Historically it was a bit fuzzy, but now it's unambiguous.
With that cleaned up, we can remove one of the global
include_directories calls and rely on CMake's
INTERFACE_INCLUDE_DIRECTORIES machinery.
(CMake's documentation and "modern CMake" prefers setting include
directories on the target and letting them flow up the dependency tree,
rather than configuring it globally across the project.)
Change-Id: I364df834d62328b69f146fbe35c10af97618a713
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56567
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Rather than trying to override the actual malloc symbol, just intercept
OPENSSL_malloc and gate it on a build flag. (When we first wrote these,
OPENSSL_malloc was just an alias for malloc.)
This has several benefits:
- This is cross platform. We don't interfere with sanitizers or the
libc, or have to mess with global symbols.
- This removes the reason bssl_shim and handshaker linked
test_support_lib, so we can fix the tes_support_lib / gtest
dependency.
- If we ever reduce the scope of fallible mallocs, we'll want to
constrain the tests to only the ones that are fallible. An
interception strategy like this can do it. Hopefully that will also
take less time to run in the future.
Also fix the ssl malloc failure tests, as they haven't been working for
a while. (Malloc failure tests still take far too long to run to the end
though. My immediate motivation is less malloc failure and more to tidy
up the build.)
Bug: 563
Change-Id: I32165b8ecbebfdcfde26964e06a404762edd28e3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56925
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We've already put perlasm.cmake in there. I figure CMake helper files
can go in there. It also seems to match what other projects too.
Change-Id: Ief6b10cf4e80b8d4b52ca53b90aa425b32037e52
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56566
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I'm not sure why I conditioned C11 on non-Clang MSVC. I think I meant to
invert that condition to NOT MSVC OR CLANG. But given that it worked,
just do it across the board.
(Though we support VS2017, which doesn't support a C11 mode, so this is
slightly curious. It may just be that pre-VS2019, this option is a
no-op.)
Change-Id: I271ffd2a913c1aa676fea7ec41f30c1896bb5955
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56325
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We've been setting /Wall on MSVC for a while, but /Wall in MSVC is
really "all". I.e., it's -Weverything in Clang and GCC, and includes
many warnings that are simply diagnostics. MSVC's own headers do not
promise to be clean under /Wall.
Rather, the equivalent of Clang and GCC's -Wall is /W4, which MSVC does
promise to pass. Under /Wall, every new MSVC release we've had to update
an ever-growing list of warning exceptions, to disable the
off-by-default warnings that were off for a reason. Switch to MSVC's
recommendations and just enable /W4.
From there, I've trimmed the exception list, now that we don't need to
re-disable disabled warnings. A few non-disabled warnings also no longer
need exceptions.
This should fix the build with VS2022, which was failing due to C5264.
C5264 flags a couple of instances in the library, but tons and tons in
MSVC headers and googletest. (The instances in the library are a little
goofy and reflect things that should have been 'inline constexpr', but
we can't rely on C++17 yet. Though I may go add a compat macro for
that.)
Fixed: 552
Change-Id: I9031c0d5bd4c7a4df1dc3040b38af9cfbcffc06e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56045
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The clang script needed to be tweaked slightly because they've since
changed the URL. Also libc++ now needs to be built as C++20. (The
bundled libc++ is only built in some of our test configs, so this
doesn't imply a C++20 dependency across the board.)
Change-Id: I0a9e3aed71268bcd37059af8549a23cfc0270b05
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55272
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
CMake 3.10 was released November 20, 2017, which is now more than five
years ago.
Change-Id: Ic939fd137983914ce1041740f58d98a56433e739
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55271
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Also build with -Wtype-limits to catch future instances.
Bug: 529
Change-Id: I2d84dc1824ffc7cd92411f49c9f953bcd3c74331
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55045
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Newer versions of Clang have a warning to detect "suspicious" uses of
string concatenation, where they think a comma or so was missing. It
flags a false positive in x509_test.cc, which we can silence with
parentheses. Fuchsia builds with this warning enabled, so enable it to
catch future instances.
I couldn't find official documentation on when this was added, but
empirically it's in my clang-12 but not my clang-11. That's recent
enough that adding a version check seems prudent. Unfortunately,
version-detecting Clang is complex because AppleClang uses completely
different versions. There's a handy table on Wikipedia that maps them.
Change-Id: I503c21d39bb5c68dda9bda6da693c7208f3af561
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54785
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CMake 3.8 was released April 10, 2017, which puts it past our five
year horizon. (CMake 3.9 is just a few days short of it, so using 3.8
for now.) In particular, depending on 3.7+ gets us some nice features
like VERSION_GREATER_EQUAL.
Change-Id: I90457ad41e7add3c6b2dd3664da964c4b6ede499
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53345
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This seems to be the preferred mechanism starting CMake 3.1, and reduces
some compiler-specific bits. We can probably also retire -stdlib=libc++
on AppleClang now. https://boringssl-review.googlesource.com/21984
suggests it was needed to make C++11 work, but presumably that's the
default stdlib now that the default C++ version is C++11.
(If it is needed, that ought to be CMAKE_CXX_STANDARD's responsibility.
I don't see any evidence of them setting it, so I'm guessing this is
just no longer needed.)
Change-Id: Ide1fdbd3d4b8fe37a10a7948171a2c20c9de21f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52647
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CMake versions newer than ~3.1x automatically determine the subdirectory under CMAKE_INSTALL_PREFIX using the type of the installed target. Older versions need this to be manually computed using the GNUInstallDirs library.
Since we override the CMAKE_INSTALL_PREFIX default, this just controls
the internal layout of the install/ directory generated underneath the
boringssl checkout.
Bug: 488
Change-Id: I97b02006301e463bb0cfd54acb2b27656484cc85
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52345
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Now that we've dropped MSVC 2015, I believe we can rely on C++14 (which
is now seven years old). This switches the build to require C++14. I've
gone ahead and switched code in both public headers and within the
library, but if the public headers are a problem, we can revert those
separately.
C++14 doesn't get us quite as much as C++17, but see if we can get to
C++14 first. Still, std::enable_if_t and the less restricted constexpr
are nice wins.
Update-Note: C++14 is now required to build BoringSSL. If the build
breaks, make sure your compiler is C++14-capable and is not passing
-std=c++11. If this is causing problems for your project, let us know.
Change-Id: If03a88e3f8a11980180781f95b806e7f3c3cb6c3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52246
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This creates an install directory under the top level source directory.
The install contains a CMake config file that produces variables and
targets compatible with FindOpenSSL, or the directory can be scanned by
FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with
third-party dependencies that find an SSL implementation via CMake.
Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
All FIPS testing is done with ACVP now. We can delete all the CAVP
stuff.
Change-Id: I459873474e40b0371f9cf760090a130ef9a90a8c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51330
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This matches the source, which only builds support for these tests on
Linux. Note Android sets CMAKE_SYSTEM_NAME to "Android", so this covers
the previous ANDROID check.
Bug: 476
Change-Id: I41ca408706d0d0c5bb22006f4c31d51fc1267f69
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51165
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
POSIX feature macros are a mess. Reportedly, FreeBSD also breaks with
_XOPEN_SOURCE, so try leaving it unset by default.
Update-Note: It's possible this will break yet another obscure UNIX.
Hopefully we can eventually find a combination that works?
Bug: 471
Change-Id: I103f8093110d343789b9c5a22eb056ab78d9cd14
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51145
Reviewed-by: Adam Langley <agl@google.com>
This is designed to be the minimal infrastructure required to support
using BoringSSL in the Rust ecosystem without fear of ABI drift. Bindgen
is used to generate Rust bindings in lockstep with the rest of the
build. `rust-openssl` can consume these generated bindings with minimal
changes.
Change-Id: I1dacd36a4131e22a930ebb01da00407e8465ad7e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49645
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This imports the changes to sha512-armv8.pl from
upstream's af0fcf7b4668218b24d9250b95e0b96939ccb4d1.
Tweaks needed:
- Add an explicit .text because we put .LK$BITS in .rodata for XOM
- .LK$bits and code are in separate sections, so use adrp/add instead of
plain adr
- Where glibc needs feature flags to *enable* pthread_rwlock, Apple
interprets _XOPEN_SOURCE as a request to *disable* Apple extensions.
Tighten the condition on the _XOPEN_SOURCE check.
Added support for macOS and Linux, tested manually on an ARM Mac and a
VM, respectively. Fuchsia and Windows do not currently have APIs to
expose this bit, so I've left in TODOs. Benchmarks from an Apple M1 Max:
Before:
Did 4647000 SHA-512 (16 bytes) operations in 1000103us (74.3 MB/sec)
Did 1614000 SHA-512 (256 bytes) operations in 1000379us (413.0 MB/sec)
Did 439000 SHA-512 (1350 bytes) operations in 1001694us (591.6 MB/sec)
Did 76000 SHA-512 (8192 bytes) operations in 1011821us (615.3 MB/sec)
Did 39000 SHA-512 (16384 bytes) operations in 1024311us (623.8 MB/sec)
After:
Did 10369000 SHA-512 (16 bytes) operations in 1000088us (165.9 MB/sec) [+123.1%]
Did 3650000 SHA-512 (256 bytes) operations in 1000079us (934.3 MB/sec) [+126.2%]
Did 1029000 SHA-512 (1350 bytes) operations in 1000521us (1388.4 MB/sec) [+134.7%]
Did 175000 SHA-512 (8192 bytes) operations in 1001874us (1430.9 MB/sec) [+132.5%]
Did 89000 SHA-512 (16384 bytes) operations in 1010314us (1443.3 MB/sec) [+131.4%]
(This doesn't seem to change the overall SHA-256 vs SHA-512 performance
question on ARM, when hashing perf matters. SHA-256 on the same chip
gets up to 2454.6 MB/s.)
In terms of build coverage, for now, we'll have build coverage
everywhere and test coverage on Chromium, which runs this code on macOS
CI. We should request a macOS ARM64 bot for our standalone CI. Longer
term, we need a QEMU-based builder to test various features. QEMU seems
to have pretty good coverage of all this, which will at least give us
Linux.
I haven't added an OPENSSL_STATIC_ARMCAP_SHA512 for now. Instead, we
just look at the standard __ARM_FEATURE_SHA512 define. Strangely, the
corresponding -march tag is not sha512. Neither GCC and nor Clang have
-march=armv8-a+sha512. Instead, -march=armv8-a+sha3 implies both
__ARM_FEATURE_SHA3 and __ARM_FEATURE_SHA512! Yet everything else seems
to describe the SHA512 extension as separate from SHA3.
https://developer.arm.com/architectures/system-architectures/software-standards/acle
Update-Note: Consumers with a different build setup may need to
limit -D_XOPEN_SOURCE=700 to Linux or non-Apple platforms. Otherwise,
<sys/types.h> won't define some typedef needed by <sys/sysctl.h>. If you
see a build error about u_char, etc., being undefined in some system
header, that is probably the cause.
Change-Id: Ia213d3796b84c71b7966bb68e0aec92e5d7d26f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50807
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This silences a pile of -Wformat-signedness warnings. We still need
casts in a few places where the API gives int but really wanted
uint16_t. There I cast to unsigned instead of uint16_t for the sake of
not losing information.
With that, we should be -Wformat-signedness-clean on GCC, so enable the
warning.
Bug: 450
Change-Id: I3ab10348bb47d398b8b9b39acf360284a8ab04d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50771
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We haven't done this in a while. This also tests more codepaths in
in the previous Python 3 update.
libc++ required a few more build tweaks. Also the CMake update was
necessary to update the NDK. Older CMake cannot detect CMAKE_LINKER
in the newer NDK.
Change-Id: I59ab1c6b074b805dd4b8a6ab596c4cf469d5bfa9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50167
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
GCC 6.1 was released more than five years ago, April 27, 2016. We can
thus drop some bits in the CMake files.
https://gcc.gnu.org/releases.htmlhttps://gcc.gnu.org/develop.html#num_scheme
Also note in BUILDING.md that VS2015 will no longer be supported next
year. Then we can cycle our CQ to testing VS2017 + VS2019. (We're
currently not testing VS2019 at all, though so far it hasn't been an
issue.) I've been running into some VS2015-only C++ issues around
conversions, so once we stop testing it, I expect it'll break.
Change-Id: I7a3020df2acd61d57409108aa4d99c840b5ca994
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48925
Reviewed-by: Adam Langley <agl@google.com>
CMake's language is rather fragile and unsound. For the most part, it is
a shell script with more parentheses. That is, it simply expands command
arguments into a list of strings and then evaluates it, complete with
shell-style differences between "${FOO}" and ${FOO}.
The if() command is special and internally also expands variables. That
is why things like if(FOO STREQUAL "BAR") work. CMake interprets "FOO"
as a variable if it can find a variable, or a string otherwise. In
addition to getting very confused on typos, it means that
if("${FOO}" STREQUAL "BAR") will double-expand, and it will do strange
things if BAR is a variable.
CMP0054 patches this (which we set by minimum version) so that if() only
expands if the token was unquoted. This fixes
if("${FOO}" STREQUAL "BAR"). However, if(${FOO} STREQUAL "BAR")
continues to double-expand FOO.
We had a mix of all three of FOO, ${FOO}, and "${FOO}". It's not clear
which is the canonical spelling at this point, but CMake own files
(mostly) use FOO, as do most of our lines, so I've standardized on that.
It's a little unsatisfying if we typo a variable, but I suppose ${FOO}
also silently ignores unset variables.
Bug: 423
Change-Id: Ib6baa27f4065eed159e8fb28820b71a0c99e0db0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48705
Reviewed-by: Adam Langley <agl@google.com>
GCC 4.9.0 was released April 2014, which was well over five years ago.
Change-Id: Ib26d459ed82a7af671b8524a334a6f99eacb003e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46346
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Windows on Arm (WoA) builds are currently using the C implementations
of the various functions within BoringSSL. This patch enables feature
detection for the Neon and hardware crypto optimizations, and updates
the perl script to generate AArch64 .S files for WoA.
Note these files use GNU assembler syntax (specifically tested with
Clang assembler), not armasm.
Change-Id: Id8841f4db0498ec16215095a4e6bd60d427cd54b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43304
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This change causes the run_tests target, in FIPS builds, to run ACVP
for each supported algorithm. For most of them the output can be compared
against a known result. For some of them the output is too variable and
they are only run to ensure that they don't have local errors.
The ACVP test vectors have been trimmed significantly because they're
often huge. Firstly an included tool drops all but one test from each
group. Some vector sets have been manually trimmed to remove tests that
cause variable output.
Change-Id: Iff73851e3d47813041cc7ea6d881282750274940
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
David Benjamin
Rebecca Chang Swee Fun
Daniel Thornburgh
Adam Langley
Benjamin Brittain
Anthony Roberts