e4acd6cb568214b1c7db4e59ce54ea2e1deae1f5 enabled assembly for more
platforms on Android, but the way Android's FIPS build is set up, we
currently require ld -r to work on any platform with assembly. See
b/294399371.
This should be fixable with more time spent on the Android build (and
possibly missing features added to Soong, as Soong is quite limited),
but as we've never had assembly working here, just restore the old state
of things.
Change-Id: I8f4e66979a003a5692389ef7e127c8d9f1630773
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62165
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
While it's the same code path, NIST may consider these different
functions and thus want separate checks for them.
Change-Id: Ic391b5e656b22c5e11d94ec22398346669833bd9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62087
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
They are NIST hash functions, but this service indicator function is
specific to their use in the TLS KDF.
Change-Id: I5a1f9d2865813f436a8e2a7548dffefcb2813c5f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62086
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
With b/291102972 resolved, we can try this again.
Bug: 629, b:291102972
Change-Id: Ic04d1855f185ead6ae2e151dcc56493afce40b4f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62105
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
These should not be necessary as of aosp/2673984.
Bug: 542
Change-Id: Ice0d8a6c535bb2bd4549cbf88197a36c8e859e74
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62085
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
cpu_arm_openbsd.c is the same as OPENSSL_STATIC_ARMCAP.
cpu_aarch64_freebsd.c is the same as cpu_aarch64_sysreg.c. (The FreeBSD
one was using the macros in their headers, but those macros expand to
the same inline assembly.)
Also send ANDROID_BAREMETAL + 32-bit Arm to OPENSSL_STATIC_ARMCAP. This
way we can remove OPENSSL_STATIC_ARMCAP from the Android baremetal build
without having to chase down constraining it to aarch64. See
b/291106677#comment6
Update-Note: This is a slight change to the OpenBSD build. Previously,
we assumed OpenBSD on 32-bit Arm implies NEON. Now, we pick it up from
the __ARM_NEON define from ACLE, i.e. whether the compiler has been told
that NEON is available. (This comes from -march or other options.) Doing
that is desirable anyway: if NEON is in your baseline, you should tell
your compiler so it can vectorize loops.
Change-Id: Icd43a2b56bb6e3f04f0fed996ae750fba65e3312
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62066
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Provide an implementation of OPENSSL_cpuid_setup() which identifies the
available CPU features required by the library directly from the system
registers for baremetal AArch64 builds without static initializer
(OPENSSL_NO_STATIC_INITIALIZER) that don't configure static capabilities
(OPENSSL_STATIC_ARMCAP). This assumes that the client code is NOT
running at exception level EL0 (userspace) and is enabled for
ANDROID_BAREMETAL.
Bug: b:265125189
Change-Id: Ifee6fbd24ece823a4661dd984f89473e1e1e3eda
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58586
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Tested in aosp/2673719. As a bonus, this will increase asm coverage on
Android. Right now they're not building the macOS assembly.
Bug: 542
Change-Id: I02f77831566bba55bb204cb08c1e1e972e03b90b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62005
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Pretty much all of std::span and base::span are constexpr. der::Input
similarly has constexpr bits. So we can use bssl::Span in der::Input,
align bssl::Span in constexpr-ness.
Also fix const-ness of first() and last().
Bug: chromium:770501
Change-Id: Ic0031cd955d8ac0af9c3cb928411f23a34820347
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61945
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Adds general_names and crl unittests to pki tests, with
associated data files for crl unittest.
Bug: chromium:1322914
Change-Id: Idda8e4a98ef3744a76717db32628db554c12e415
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61965
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Like OPENSSL_NO_FILESYSTEM, keep us honest: if the symbol is missing,
don't declare it in the headers. This ensures folks aren't relying on
dead code elimination and then later break when they build in a context
where it doesn't happen.
Bug: 629
Change-Id: I3e56c3879e970aa8d0d6e0e5f1ad046d0f420ef0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61730
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Detecting errors (i.e. fs-less platforms using fs-only APIs) at compile
time is generally preferable to doing so at runtime, so
https://boringssl-review.googlesource.com/c/boringssl/+/61726 opted to
remove the APIs altogether on applicable targets.
However, Trusty uses rust-openssl somewhere and rust-openssl binds a
bunch of filesystem-dependent APIs unconditionally. To keep that
working, switch to a stub fopen when OPENSSL_NO_FILESYSTEM is set. We
effectively model a platform where the filesystem "exists", but is
empty. Upstream OpenSSL similarly has OPENSSL_NO_STDIO still define the
file BIO (unlike the socket BIO, which is excluded), but in a stub form.
As part of this, I've gone ahead and resolved one of the Trusty TODOs.
It does produce a duplicate symbol with [1], but things seem to link
fine in treehugger. In case it does break, I've bumped
BORINGSSL_API_VERSION, so we can go in and condition it if needed.
[1] https://android.googlesource.com/trusty/lib/+/refs/heads/main/lib/openssl-stubs/bio.c
Bug: 629
Change-Id: I4f20d872a7cde863d21c78090f270b77b03545fa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61925
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: Ic461a3890aa78109dc06ffcf144b6b7a90456ff3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61748
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Seed the corpus from cert_corpus. As part of that, check in the result of minimizing all the corpora.
Note this is just making one of the fuzzers build, I'll adapt
the others and follow on by updating the IMPORT process to do it
in a follow on cl.
Bug: chromium:1322914
Change-Id: Iea1b89f8fee938fa99c0a4d8134bcd0e7023d149
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61765
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Some platforms would not have sys/socket.h, we should guard these
socket related headers with OPENSSL_NO_SOCK.
Bug: 629
Change-Id: I2d7c31ad32d467da46114307fd89c2ba3d41df2c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61845
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
See if that helps discourage their use slightly. (Though pretty much all
the uses are problematic things like Rust and prebuilts, so they
probably won't notice.)
Change-Id: I012b68922d7b36e778488e7455908e81b3de15f7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61905
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This is a temporary workaround for b/291994116
Bug: b:291994116
Change-Id: I5b0372e07cf3bdf4b6a5b4b37dabea828ad026a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61885
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This addes enough to get it building and running tests
in google3 with some changes in the google3 BUILD file.
Change-Id: I1cf17bc602253a69420456fd6454d10cdcf6b988
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61747
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
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>
