(Only in package names. Hyphens in file names are file.)
Change-Id: I80b705a780ffbad056abe7a7868d5682b30d2d44
Reviewed-on: https://boringssl-review.googlesource.com/32144
Commit-Queue: Matt Braithwaite <mab@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
BoringSSL depends on the platform's locking APIs to make internal global
state thread-safe, including the PRNG. On some single-threaded embedded
platforms, locking APIs may not exist, so this dependency may be disabled
with a build flag.
Doing so means the consumer promises the library will never be used in any
multi-threaded address space. It causes BoringSSL to be globally thread-unsafe.
Setting it inappropriately will subtly and unpredictably corrupt memory and
leak secret keys.
Unfortunately, folks sometimes misinterpreted OPENSSL_NO_THREADS as skipping an
internal thread pool or disabling an optionally extra-thread-safe mode. This is
not and has never been the case. Rename it to
OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED to clarify what
this option does.
Update-Note: As a first step, this CL makes both OPENSSL_NO_THREADS and
OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED work. A later CL
will remove the old name, so migrate callers after or at the same time as
picking up this CL.
Change-Id: Ibe4964ae43eb7a52f08fd966fccb330c0cc11a8c
Reviewed-on: https://boringssl-review.googlesource.com/32084
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Reason codes across libraries may collide. One must never check
ERR_GET_REASON without also checking ERR_GET_LIB.
Change-Id: I0b58ce27a5571ab173d231c1a673bce1cf0427aa
Reviewed-on: https://boringssl-review.googlesource.com/32110
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <alangley@gmail.com>
This format is kind of silly, but it seems not completely unused? Add a
basic test for it before I rewrite it to fix the function pointer casts.
Change-Id: Ib2d1563419b72cf468180b9cda4d13e216b7eb3a
Reviewed-on: https://boringssl-review.googlesource.com/32108
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <alangley@gmail.com>
It's a little bit shorter.
Change-Id: Ia1ba55d20ee4f2519a017871f5f5949081569e1a
Reviewed-on: https://boringssl-review.googlesource.com/32104
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
They're not working right now.
Bug: chromium:888687
Change-Id: I723a382d666e24c4f7f35c7b9369341b4bdebf1a
Reviewed-on: https://boringssl-review.googlesource.com/32124
Reviewed-by: Adam Langley <agl@google.com>
- Add util/read_symbols.go to read exported symbols from an AR
file for use with the symbol prefixing feature
- Move util/fipstools/fipscommon/ar.go -> util/ar/ar.go
- util/ar/ar.go: Support BSD-style AR files
Change-Id: I171b3b952e69c4b87ac04751b7dba3ea9bc2504e
Reviewed-on: https://boringssl-review.googlesource.com/32024
Reviewed-by: David Benjamin <davidben@google.com>
While I don't believe EINTR can occur with a non-blocking getrandom call
when talking to the kernel directly, that may not be true when certain
sandboxing systems are being used.
Additionally, with this change we will no longer silently ignore errors
other than ENOSYS.
Update-Note: update internal bug 115344138.
Change-Id: I952c132cf325dcc17dc38e68f054abc41de1f8b0
Reviewed-on: https://boringssl-review.googlesource.com/32006
Reviewed-by: David Benjamin <davidben@google.com>
This function doesn't actually exist. (If it did, it would be the same as
SHA512_Transform. We currently omit SHA224 and SHA384's low-level transform
functions.)
Change-Id: Ia9d3d7c86e8f70fd5e4f13b8de4f08440dccbdcb
Reviewed-on: https://boringssl-review.googlesource.com/32064
Reviewed-by: Adam Langley <agl@google.com>
We no longer need to fork them. This is in preparation for pulling it
via Go modules, but probably need to figure out the network issue first.
Slightly bad manners for CI to do that.
Change-Id: Ic258264f3c3559817d5e4921e4ad3282e94d05fe
Reviewed-on: https://boringssl-review.googlesource.com/31904
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This makes running go test, etc., in util/fipstools/delocate work! This
adds a go_executable command to CMake like:
go_executable(delocate boringssl.googlesource.com/boringssl/util/fipstools/delocate)
which internally gets dependencies and whatnot so it behaves like usual
Go.
Update-Note: delocate has been rearranged a bit.
Change-Id: I244a7317dd8d4f2ab77a0daa624ed3e0b385faef
Reviewed-on: https://boringssl-review.googlesource.com/31885
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This avoids needing to duplicate the "This API differs [...]" comment.
Change-Id: If07c77bb66ecdae4e525fa01cc8c762dbacb52f1
Reviewed-on: https://boringssl-review.googlesource.com/32005
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
EVP_AEAD reused portions of EVP_CIPHER's GCM128_CONTEXT which contains both the
key and intermediate state for each operation. (The legacy OpenSSL EVP_CIPHER
API has no way to store just a key.) Split out a GCM128_KEY and store that
instead.
Change-Id: Ibc550084fa82963d3860346ed26f9cf170dceda5
Reviewed-on: https://boringssl-review.googlesource.com/32004
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This should make it easier for us to reuse Go code properly.
util/fipstools is kind of a mess. runner has been using relative
imports, but Go seems to prefer this mechanism these days.
Update-Note: The import spelling in ssl/test/runner changes. Also we now
require Go 1.11. Or you could clone us into GOPATH, but no one does
that.
Change-Id: I8bf91e1e0345b3d0b3d17f5c642fe78b415b7dde
Reviewed-on: https://boringssl-review.googlesource.com/31884
Reviewed-by: Adam Langley <agl@google.com>
Providing a size hint to the allocator is substantially faster,
especially as we already know/need the size for OPENSSL_cleanse.
We provide a weak symbol that falls back to free when a malloc with
sdallocx is not statically linked with BoringSSL.
Alternatives considered:
* Use dlsym(): This is prone to fail on statically linked binaries
without symbols. Additionally, the extra indirection adds call
overhead above and beyond the linker resolved technique we're using.
* Use CMake rules to identify whether sdallocx is available: Once the
library is built, we may link against a variety of malloc
implementations (not all of which may have sdallocx), so we need to
have a fallback when the symbol is unavailable.
Change-Id: I3a78e88fac5b6e5d4712aa0347d2ba6b43046e07
Reviewed-on: https://boringssl-review.googlesource.com/31784
Reviewed-by: Chris Kennelly <ckennelly@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This was added to support the no_certificate warning alert in SSLv3. That has
since been removed. In the long run, I would like for ssl_send_alert to go
through a flow similar to add_alert so the BIO-free APIs work right and avoid a
host of strangeness surrounding wpend_buf. For now, remove the unused hook.
Change-Id: I1995028b8af4ffa836028794e6b33b2cd1b2435b
Reviewed-on: https://boringssl-review.googlesource.com/31984
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Unsurprisingly it doesn't work.
Change-Id: Ida2b9879184f2dfcce217559f8773553ecf0c33d
Reviewed-on: https://boringssl-review.googlesource.com/31947
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
In particular, pull Go 1.11 to get module support. Also we don't need to
pull in libfuzzer anymore.
Change-Id: I8098f64cef59422d9d43f7eca5bf3ced69eb70c4
Reviewed-on: https://boringssl-review.googlesource.com/31864
Reviewed-by: Adam Langley <agl@google.com>
BSSL_NAMESPACE_BEGIN needs to be defined unconditionally.
Change-Id: I1770ca6b6c19f9c732ef00ba8c89b112b421929d
Reviewed-on: https://boringssl-review.googlesource.com/31824
Reviewed-by: Adam Langley <agl@google.com>
The check of `r` instead of `rr` was introduced in change
I298400b988e3bd108d01d6a7c8a5b262ddf81feb.
Change-Id: I4376a81c65856f6457b0a11276176bf35e9c647d
Reviewed-on: https://boringssl-review.googlesource.com/31844
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Perl's print doesn't automatically include a newline and the delocate
script doesn't like files that don't end with one.
Change-Id: Ib1bce2b3bb6fbe1a122bd88b58198b497c599adb
Reviewed-on: https://boringssl-review.googlesource.com/31804
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
MSAN is incompatible with hand-written assembly code. Previously we
required that OPENSSL_NO_ASM be set when building with MSAN, and the
CMake build would take care of this. However, with other build systems
it wasn't always so easy.
This change automatically disables assembly when the compiler is
configured for MSAN.
Change-Id: I6c219120f62d16b99bafc2efb02948ecbecaf87f
Reviewed-on: https://boringssl-review.googlesource.com/31724
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This doesn't really matter, but once less visible symbol.
Change-Id: If4ee8cfe5c9db9d1c05ca74b8c6fee5cf3ea5a9b
Reviewed-on: https://boringssl-review.googlesource.com/31764
Reviewed-by: Adam Langley <agl@google.com>
The assembly files need some includes. Also evp.h has some conflicting
macros. Finally, md5.c's pattern of checking if a function name is
defined needs to switch to checking MD5_ASM.
Change-Id: Ib1987ba6f279144f0505f6951dead53968e05f20
Reviewed-on: https://boringssl-review.googlesource.com/31704
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Also point out that we're a cryptography library, not a text encoding library.
Not that that'll dissuade anyone.
Change-Id: Ia324e08c5cdd108fa182d2610f80447262e0bd5c
Reviewed-on: https://boringssl-review.googlesource.com/31664
Reviewed-by: Adam Langley <agl@google.com>
We're a far cry from the good old days when we just read from /dev/urandom
without any fuss...
In particular, the threading logic is slightly non-trivial and probably worth
some basic sanity checks. Also write a fork-safety test, and test the
fork-unsafe-buffering path.
The last one is less useful right now, since fork-unsafe-buffering is a no-op
with RDRAND enabled (although we do have an SDE bot...), but it's probably
worth exercising the code in
https://boringssl-review.googlesource.com/c/boringssl/+/31564.
Change-Id: I14b1fc5216f2a93183286aa9b35f5f2309107fb2
Reviewed-on: https://boringssl-review.googlesource.com/31684
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Historically, OpenSSL filled in a fake session ID for ticket-only
client sessions. Conscrypt relies on this to implement some weird Java
API where every session has an ID and may be queried out of the client
session cache and, e.g., revoked that way.
(Note that a correct client session cache is not keyed by session ID and
indeed this allows one server to knock out another server's sessions by
matching session IDs. But existing APIs are existing APIs.)
For consistency between TLS 1.2 and TLS 1.3, as well as matching
OpenSSL's TLS 1.3 implementation, do the same in TLS 1.3. Note this
smooths over our cross-version resumption tests by allowing for
something odd: it is now syntactically possible to resume a TLS 1.3
session at TLS 1.2. It doesn't matter either way, but now a different
codepath rejects certain cases.
Change-Id: I9caf4f0c3b2e2e24ae25752826d47bce77e65616
Reviewed-on: https://boringssl-review.googlesource.com/31525
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Flattening the build seems to have changed the order of actions when
using Make and output directories for perlasm are no longer created
before Perl is run. Additionally, if the output directory doesn't exist,
the perlasm scripts seem to output to stdout instead.
Change-Id: I59b801f7347951a3b9cef2ff084b28a00b2d5a3c
Reviewed-on: https://boringssl-review.googlesource.com/31645
Reviewed-by: Adam Langley <agl@google.com>
(I'm not sure why this built anywhere, but it did.)
Change-Id: I47e5b9b689c597e38a74104ac9ddcadfc2fb063d
Reviewed-on: https://boringssl-review.googlesource.com/31644
Reviewed-by: Adam Langley <agl@google.com>
Not sure that I think this is a very valid build error from GCC, but
it's easy enough to work around.
../crypto/cpu-arm-linux_test.cc: In member function ‘virtual void ARMLinuxTest_CPUInfo_Test::TestBody()’:
../crypto/cpu-arm-linux_test.cc:25:10: error: declaration of ‘struct ARMLinuxTest_CPUInfo_Test::TestBody()::Test’ shadows a previous local [-Werror=shadow]
struct Test {
^~~~
In file included from ../crypto/cpu-arm-linux_test.cc:19:
../third_party/googletest/include/gtest/gtest.h:375:23: note: shadowed declaration is here
class GTEST_API_ Test {
Change-Id: Icc1676a621ec26b3665adaf5daf7d6c6f5307ba8
Reviewed-on: https://boringssl-review.googlesource.com/31624
Reviewed-by: Adam Langley <agl@google.com>
The fipsmodule is still separate as that's a lot of build mess. (Though
that too may be worth pulling in eventually. CMake usually has different
opinions on generated files if they're in the same directory. We might
be able to avoid the set_source_properties(GENERATED) thing.)
Change-Id: Ie1f9345009044d4f0e7541ca779e01bdc5ad62f6
Reviewed-on: https://boringssl-review.googlesource.com/31586
Reviewed-by: Adam Langley <agl@google.com>
It was pointed out that "a reference" to C++ programmers means something
very different from what we intend.
Change-Id: I508196f8e3427ea71439c7871eae9b735a4fa5ca
Reviewed-on: https://boringssl-review.googlesource.com/31544
Reviewed-by: Adam Langley <agl@google.com>
I realized looking at the sigalgs parser that I messed up the
space-splitting logic slightly. If the CPU features are "foo bar baz",
it would not parse "baz". This doesn't particular matter (the last one
is "crc32"), but better to parse it correctly.
Fix this and add a unit test. While I'm here, may as well add a fuzzer
too.
Change-Id: Ifc1603b8f70d975f391d10e51ede95deec31a83d
Reviewed-on: https://boringssl-review.googlesource.com/31464
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
In particular, we often don't say anything if using the "default" conventions,
but we don't say what those are. We've also never documented
get0/get1/set0/set1.
Change-Id: I113593cfcdcb93e0009796649e4c19219e765caf
Reviewed-on: https://boringssl-review.googlesource.com/31504
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This removes the special-case for #defines in doc.go.
Change-Id: I6bf750485a94ad28c3975644c74a17c550bb3224
Reviewed-on: https://boringssl-review.googlesource.com/31505
Reviewed-by: Adam Langley <agl@google.com>
https://boringssl-review.googlesource.com/31085 wasn't right. We already forbid
creating BN_MONT_CTX on negative numbers, which means almost all moduli already
don't work with BN_mod_exp_mont. Only -1 happened to not get rejected, but it
computed the wrong value. Reject it instead.
Update-Note: BN_mod_exp* will no longer work for negative moduli. It already
didn't work for all negative odd moduli other than -1, so rejecting -1 and
negative evens is unlikely to be noticed.
Bug: 71
Change-Id: I7c713d417e2e6512f3e78f402de88540809977e3
Reviewed-on: https://boringssl-review.googlesource.com/31484
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I45866c3a4aa98ebac51d4e554a22eb5add45002f
Reviewed-on: https://boringssl-review.googlesource.com/31404
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This often causes confusion since, for various silly reasons (intrinsic
ref-counting, FOO_METHOD, and RSA's cached Montgomery bits), the thread
safety of some functions don't match the usual const/non-const
distinction. Fix const-ness where easy and document it otherwise.
Change-Id: If2037a4874d7580cc79b18ee21f12ae0f47db7fd
Reviewed-on: https://boringssl-review.googlesource.com/31344
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Update-Note: If not explicitly configured to use tls13_all, callers that enable
TLS 1.3 will now only enable the final standard version.
Change-Id: Ifcfc65a9d8782c983df6e002925e8f77f45b6e53
Reviewed-on: https://boringssl-review.googlesource.com/31384
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Matthew Braithwaite
David Benjamin
Joshua Liebow-Feeser
Adam Langley
Chris Kennelly
Phillipp Schoppmann
Adam Langley