This warning was being tripped because lib_buf and reason_buf made GCC,
incorrectly, believe that the strings could get that long, and then
attempted to sum up the snprintf to 120, obtained by inlining some
things.
Those buffers were larger than they needed to be, so bringing it down is
sufficient to silence things. That said, the buffer bounds are supplied
by the caller and it is expected that truncation can occur, so the
warning is just incorrect. The warning can also be silenced by checking
the snprintf return value. As we're already trying to detect truncation,
we may as well do it with the return value and skip the extra strlen
call.
Either of the two changes is sufficient to suppress the warning, but
both seem worthwhile, so I've done them both.
Change-Id: Ia1b1de67bba55da6f0d07e3682165a1820ce2c9e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61805
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
As part of this, factor out some of the socket bits. I tried to write
the sockaddr mess in a way that's strict-aliasing-clean, at least as far
as code we own goes. But the API is really not designed for it, and who
knows what effective type the underlying libc functions expect.
(Fortunately it's mostly syscalls, which definitely escape the
abstract machine.)
Change-Id: I12621f6c40f074ff7423dd46ddceca120ba63db9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61728
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These functions are just wrappers over BIO_ctrls, shared between the fd
and socket BIOs. Though we don't currently support one, it is
conceivable that there would be a platform with socket BIOs but not fd
BIOs. In that case, the BIO_get_fd function would still be useful to
implement SSL_get_rfd. (And someone could conceivably implement it in
another BIO.)
Bug: 629
Change-Id: I7ac3561f76af86af32d70b1c6265c4caeaecb129
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61727
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This corresponds to the libcrypto_baremetal build target in Android,
which is an embedded-style platform that uses a subset of the bionic
libc. It will also, eventually, use getentropy for its PRNG.
As part of this, generalize the OPENSSL_TRUSTY exclusion for file BIOs
to OPENSSL_NO_FILESYSTEM. Upstream OpenSSL uses OPENSSL_NO_STDIO, but
that excludes all of FILE entirely. We already require FILE in quite a
few places (urandom.c, self_test.c) for writing to stderr, and FILE is
part of C standard library. So, let's tentatively say that we require
you have FILE and stderr.
Instead, OPENSSL_NO_FILESYSTEM is saying you don't have fopen. You're
still required to have the three std{in,out,err} FILEs, and given a
FILE, you need to allow the standard operations on it. (Possibly in
forms that always fail.)
To keep us honest, whenever a function is excluded, I've dropped it from
the header too, and followed callers up the chain. I have not attempted
to make the tests work when these are excluded. Later CLs in this series
will do the same for NO_SOCK and NO_POSIX_IO. This was a little tedious,
but not too bad.
(I assume we'll end up changing our minds on this a lot. For now, let's
try this.)
I haven't yet restored OPENSSL_RAND_TRUSTY or removed the OPENSSL_TRUSTY
ifdef on file.c. Having a separate CL makes it a bit easier to revert if
something goes wrong.
This depends on
https://android-review.googlesource.com/c/platform/bionic/+/2659335,
which fixes the header bionic uses for getentropy.
Bug: 629, b:291102972
Change-Id: Idd839cd3fa4253128de54bd1be7da261dbcdeb7c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61726
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Change-Id: I690f56f2164936b005b672f896858b027a79c011
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61745
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/61685 had the
side effect of unobscuring some snprintf calls to GCC. There are a
couple instances that cannot truncate, but GCC doesn't know this because
it doesn't know the bounds on struct tm.
Fortunately, -Wformat-truncation, at level 1, is satisfied by checking
the return value, so do that.
Change-Id: Iad3ae0d51a951c10f1b706be7f6e127f0b9e6dee
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61705
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
One less thing to update when we next bump the minimum.
Bug: 607
Change-Id: I50bd01b14499a7ed7904a5e111c3e1df57eaa144
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61645
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Our BIO_snprintf is just a thin wrapper over the libc one, and we
already call it directly in other places. Just call the libc one
consistently.
Change-Id: Ia7daf26b9789ddcecab67118c4ec4a077aad5a22
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61685
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We'd leak the socket if Connect failed in the middle. (This doesn't
especially matter. The test process would just exit anyway.)
Change-Id: I8e1f252781810b1d8ef3c41bd707dfebb0371e60
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61665
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
glibc and musl do not make getentropy available from <unistd.h> unless
_BSD_SOURCE (or _GNU_SOURCE) is defined. _BSD_SOURCE, in glibc, triggers
a deprecation warning to use _DEFAULT_SOURCE instead.
It seems _DEFAULT_SOURCE might be fairly broadly defined, but some
Emscripten-based toolchain (which uses musl) didn't end up defining
it for some reason. Just do it explicitly in the source file so it
always works.
Change-Id: I4532d4adb9f8ed55c43763ca2dd426b5fa1b4f5c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61625
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This CL adds the Shipped field (and may update the
License File field) in Chromium READMEs. Changes were
automatically created, so if you disagree with any of
them (e.g. a package is used only for testing purposes
and is not shipped), comment the suggested change and
why.
See the LSC doc at go/lsc-chrome-metadata.
Bug: b:285450740
Change-Id: I63755d8a42ea69ff6d3a4e0c21ddacd2b7ce9053
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61545
Auto-Submit: Anne Redulla <aredulla@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This doesn't remove the old ones yet as we'll need a corresponding
downstream change. This does all of them but Soong. I think, for Soong,
we can apply the change unilaterally in the source list, but I'm holding
off on testing that until I've gotten Android updated to a more recent
BoringSSL.
Bug: 542
Change-Id: I30921ac251f76e3ecb50df9ff757fec4031e7dbc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61528
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-Note: I believe all GN and Bazel consumers have been migrated to
the new style of asm source list, so this change should be a no-op. If
any remain that still need the old ones, either migrate them to
crypto_sources_asm and crypto_sources_nasm, or let us know.
Bug: 542
Change-Id: I57052331ae56a081117b1a2df31f828943a6d13b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61527
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
BoringSSL cannot support any build configurations where a platform
claims to be something but is not. Different embedded targets need their
own define.
Bug: b:291102972
Change-Id: I91db6ddd823b0d8b7b52580f7a6c498e55da6b79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61605
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This effectively reverts
https://boringssl-review.googlesource.com/c/boringssl/+/61465, as a
temporary workaround for b/291102972. Once the broken
libcrypto_baremetal target in Android is fixed, we'll restore this file.
Bug: b:291102972
Change-Id: I830b61219e863cd7a72858a44df5fd958b023fd0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61585
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
GCC does not have __has_feature, so writing #if __has_feature(foo),
without a guard, will cause GCC to error. This is tripping the gRPC
update.
Prior to https://boringssl-review.googlesource.com/c/boringssl/+/60765,
this worked because the preamble to every assembly file would define the
missing __has_feature macro as part of detecting MSan. Now we pick up
the logic in <openssl/base.h>, which tries not to stomp over symbols we
don't own. This had the side effect of removing the __has_feature
polyfill.
Though "public", <openssl/asm_base.h> is not really a public header, so
we could put the __has_feature polyfill in there. But we already have a
pattern for detecting sanitizers in <openssl/target.h>, so just switch
to that one.
Change-Id: I747b4513f1b2f189d2df629149f22fd0fa490257
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61565
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Possibly we should run this on macOS too, so we have better test
coverage.
Bug: 287
Change-Id: I3005a445f8cb7559e91317be91a42c1db15f081a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61529
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Due to b/290792019 and b/290785937, we need them to actually exist at
the original symbols. For all of Rust's language-level safety benefits,
the ecosystem seems determined to undo it with patterns that are even
less safe than C.
This is not great and the bugs need to be fixed, but do this for now to
unblock the Android update.
Change-Id: Ia883336879779f652e7320cecdd5ca843996f6a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61525
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
file_test_gtest.cc depends on GetTestData which, for now, only exists in
crypto_test because of how the crypto_test_data machinery works. Ideally
that would be fixed but, for now, move the file out of test_support.
Things were previously building because we were relying on the static
linker to drop the file in the other targets, before the linker would
notice the undefined symbol. I'm not sure what's different about
Chromium, but somehow Chromium is sensitive to this.
Bug: 542
Change-Id: I38c7719e7c3f27bcfeeab9693fcd43fbd0300799
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61526
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Also remove unnecessary EC_GROUP_free calls. EC_GROUP_free is only
necessary in codepaths where arbitrary groups are possible.
Bug: 20
Change-Id: I3dfb7f07b890ab002ba8a302724d8bc671590cfe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60932
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If we are working with predownloaded test vectors we don't have
connection config file and don't want to connect to remote server.
So, skip this step.
Change-Id: I8a8c558ab11306850e39dfcda0e1c38c6d238a7a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60865
Auto-Submit: Yurii Shutkin <shutkin@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Add a rand_extra file for trusty, bump the BORINGSSL_API_VERION
and mark both trusty and windows as non-forking so we do not
require fork detection support.
Update-Note:
Prior to API version 24, Trusty maintained their own CRYPTO_sysrand
implementations outside of the BoringSSL tree. With this change
they are not expected to provide CRYPTO_sysrand, it is maintained
inside the BoringSSL tree.
Change-Id: Iabcef024ff85bd767e2869a6ff27a64236322325
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61465
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We've required C++14 for a while now. As we're mostly C with a little
C++, this is less helpful, but may as well avoid bare new where
possible.
Change-Id: Icf3386e3f3b6f2092bb0089ed874cc50985f1a40
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61429
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This replaces our dynamically creating singleton EC_GROUPs from curve
data with static EC_GROUP instances.
They're just shy of being fully static because delocate still forces us
go to through CRYPTO_once to initialize structures with pointers.
(Though, without delocate, the loader would need similar initialization
via a runtime relocation.)
This means we can now have functions like EC_group_p256(), analogous to
EVP_sha256(). These are infallible functions that return const EC_GROUP
pointers. Although there is an initial 2KiB hit to binary size (now we
precompute a few more Montgomery values), I'm hoping it'll eventually
help binaries that only use a few of the curves to drop the others. Also
it removes some locks used to initialize the static curve objects, as
well as removing an annoying error condition.
Bug: 20
Change-Id: Id051c5439f2b2fe2b09bf10964d656503ee27d9e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60931
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This function hasn't done anything since 2015, when
https://boringssl-review.googlesource.com/5792 made it a no-op.
Also move RAND_get_system_entropy_for_custom_prng under obscure
functions. It's usually not what you want.
Change-Id: Ica57552792acff3c5991e6db09c15112db09d133
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61505
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This was, I assume, needed for cross-version tests, but we're long past
2020 now. While I'm here, switch a unique_ptr(new T) into make_unique as
we can rely on C++14 now.
Change-Id: I3f2fde90f124522c21868c15217f607b7f6d75db
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61428
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
They end up in uint64_t frequently right now just because the CBS APIs
use uint64_t, but we don't actually accept that large of an iteration
count.
Also use uint32_t instead of unsigned. This type should be sized based
on how large of an iteration count we think is reasonable, not something
platform-dependent.
Bug: 516
Change-Id: Ie5ff379af6bc65c5e4d25f4d10774bd819f08a50
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61426
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: Ie64ed383a1f6b63a0624c8a6f64d92a33dabf56e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61485
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Also fix the comments for ERR_STATE because they were actually wrong.
Bug: 516
Change-Id: I3b352fc75e63075a9f02f33c6e23da0f821a323e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61425
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This allows operating systems to insist on IBT
enforcement as an exploit mitigation mechanism without
needing to make an exception for anything using a
bundled boringssl, such as chrome, mono, and qtwebengine.
Change-Id: Iac28dd3d2af177b89ffde10ae97bce23739feb94
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Another point indirection removed. As part of this, remove the extra
copy of one and just use generator.raw.Z.
Bug: 20
Change-Id: I066f624fe02e17082383afc15871ab2431e97b61
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60930
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Instead, rely on internal.h to either include the header or polyfill it.
On Windows, we don't (yet) require C11, so we can't rely on the header
being directly includable. Though given it took a couple months to
notice this, it's clear the non-C11 path is pretty much untested, so we
need to get rid of it.
Bug: 624
Change-Id: I86a6961c93161c3adfacd374affb8bfb2be0a542
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61445
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Bug: 287
Change-Id: Ia907c5dd7fd31e95098730673d2da1bede6d79ed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61405
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The delocate machinery makes it annoying to have pointers in structures.
Also this is a hair more compact.
Bug: 20
Change-Id: I2bc2dd97018277b5be55fd560f4171b7b85928ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60929
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This changes the order of things so that by default your
system is expected to provide us with a getentropy() in
<unistd.h> for integrators that are not explicitly
supported.
We preserve the getrandom/urandom dance for Linux and Android
for now.
Linux has had getentropy() in libc's since 2017
macOS, and all the BSD's have had it for any versions we
care about.
iOS hides it from us - so we use CommonCrypto CCRandomGenerateBytes
Update-Note: Non-macOS Apple platforms now use CCRandomGenerateBytes
instead of /dev/urandom. Linux behavior remains unchanged. Platforms
which were not explicitly supported with a different codepath will also
switch from /dev/urandom to getentropy. If your platform specifically
requires /dev/urandom, let us know.know
Bug: 287
Change-Id: I0c2b8c594c473e4395379f50b0c4e6713c0a4c02
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61325
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
libpki.so moved and I forgot to upload this script.
Change-Id: I920c1bd506f7e3848a47729cb70ecf72402e0b49
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61345
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
As part of this, align the generated and standalone builds in how
crypto/test/gtest_main.cc is added. Since not all test targets
(urandom_test) include gtest_main.cc, and the generated one just
manually adds it to the file lists, just put it into the file lists
ahead of time. That way we don't need to synchronize the dependency
information with the generated build.
This also aligns the generated build with
https://boringssl-review.googlesource.com/c/boringssl/+/56567 to put
files like crypto/test/abi_test.cc and crypto/test/file_test_gtest.cc in
the test_support library.
Update-Note: If something odd happens with the test_support library in
downstream builds, this CL is probably to blame.
Bug: 542
Change-Id: I235e0ccd0432f4b380a92b265ede35eb8a6a6e36
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61288
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
CMake and the generate builds now broadly share a source of truth for
the test files.
Update-Note: In the standalone CMake build, build/crypto/crypto_test is
now build/crypto_test, etc. For now, the build still copies the outputs
to the subdirectories (it's cheap and avoids some workflow turbulence),
but I'm thinking we keep that for six months or so and then remove it.
Bug: 542
Change-Id: I8f97e1fcedea1375d48567dfd2da01a6e66ec4e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61286
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
One less value to initialize statically. Also this simplifies EC_GROUP
initialization. While I'm here, reorder EC_GROUP to pad better.
This lets us simplify the init bits slightly. It does mean p224-64.c,
the one EC_GROUP that doesn't use Montgomery reduction, carries around a
wasted Montgomery context, but it'll make generating the tables
statically much easier. Also once the data is pre-generated, the cost is
minimal.
Bug: 20
Change-Id: Ib66e655ce5a0902ab3ed6695fcbb46aa87683885
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60928
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit 28e4a1b838b2ffbf9e2151ae5fcfffe5ab0ffac0. Bazel
broke --cxxopt on Windows in
https://github.com/bazelbuild/bazel/issues/15073, which means projects
enabling, say, C++20 with --cxxopt=/std:c++20 are silently passing
/std:c++20 to our C files.
This is already a problem, but MSVC is smart enough to silently ignore
the flag when building C. However, MSVC will report an error if you then
pass /std:c++20 /std:c11 into the same command. It seems that check is
not aware of this ignoring behavior.
Ultimately, this is a Bazel bug, and one that makes the broken versions
of Bazel unsuitable for use with C. This was fixed in Bazel in
https://github.com/bazelbuild/bazel/pull/18119 and backported to the
upcoming Bazel 6.3.0 release in
https://github.com/bazelbuild/bazel/pull/18552
Temporarily revert the change. When Bazel 6.3.0 is released, we'll put
this back and require Windows users use a functioning version of Bazel.
Bug: 624
Fixed: 623
Change-Id: I68d9b2ed8751b4cf5dc7f42f8c1fbd42a97d6ca2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61365
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This removes a place where we make hard-coded assumes about test names.
Also it shards pki_test, as that test suite is large enough to benefit
from it.
Change-Id: I392254b73a2df2f022ccf13508552372c103bff7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61285
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This achieves much of the same goals as
https://boringssl-review.googlesource.com/c/boringssl/+/61245, but
reuses the existing source.cmake parser in generate_build_files.py.
There are two practical differences here:
First, CMake knows that, if it sees include(sources.cmake), it should
add sources.cmake as a dependency of build.ninja, and re-run cmake if
source.cmake changes. It does not know this for file(STRINGS). This can
be fixed with CMAKE_CONFIGURE_DEPENDS, but since we already have this,
may as well use it.
Second, sources.cmake wants paths rooted at the top-level BoringSSL
source directory, which means we want to define the targets at the top
level, rather than in subdirectories. While it will make the top-level
CMakeLists.txt larger, I think this is a good move:
- ./build/crypto_test --gtest_filter=... is just less annoying to type
than ./build/crypto/crypto_test --gtest_filter=...
- It will (eventually) mean libcrypto.a lives at build/libcrypto.a
instead of build/crypto/libcrypto.a. This means we can pass a single
-L parameter when building things against BoringSSL, without relying
on the install target.
- It aligns with the generated CMake build. I would like, long-term, to
stop maintaining multiple CMake builds, and the generated one seems to
have a better convention. And one that will be more disruptive to
others if we change it.
- Top-level-rooted paths are more convenient for generate_build_files.py
to work with, because that's what we want to output.
As I get further along in 542, I expect I'll move this once again,
possibly to some JSON file, because I'll need my new pregenerate tool to
parse it (and we'll no longer be constrained by what's easy to consume
in CMake), but use this for now.
Bug: 542
Change-Id: I1e8b894057264da5d7624a1fbb92f9e1198ea38e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61266
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
One less value to initialize statically. Instead, just check if r +
order < p. It's one additional comparison, but those have negligible
cost here.
Bug: 20
Change-Id: Iabc9c1894b58aeba45282e3360e38fe843eb7139
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60927
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
