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>
With Clang 6.0, libFuzzer is now included and there's a new
-fsanitize=fuzzer command to enable the needed compiler actions.
Change-Id: If8c0d649f494655c5bb1e55ebdbf39450940c75b
Reviewed-on: https://boringssl-review.googlesource.com/31324
Reviewed-by: David Benjamin <davidben@google.com>
In order to work around server bugs (see https://crbug.com/363583) we
need to ensure that the final extension is not empty. Doing this by
fixing the order of extensions is a little error-prone. Instead, insert
a padding extension to ensure this as neeeded.
Change-Id: I90760f2e6735082386c484c956a470aef38ed109
Reviewed-on: https://boringssl-review.googlesource.com/31284
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
The client downgrade detection tests were not asserting on the error (would
have caught the missing error string). Additionally, Downgrade-FalseStart-Draft
isn't testing what it's supposed to; it doesn't actually configure a draft
version or anything. Fix that and have it use ALPN rather than NPN, to match
the test above.
Change-Id: I0b759385641aa00994a912303a6f5bd65522b4bb
Reviewed-on: https://boringssl-review.googlesource.com/31204
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>
make_errors.go didn't seem to get run.
Change-Id: I12739fbab75b9f4898f73f206e404d101642b9c0
Reviewed-on: https://boringssl-review.googlesource.com/31184
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Ifd7239106471bb59057b0a65c6e91837379c78bf
Reviewed-on: https://boringssl-review.googlesource.com/31164
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>
Change-Id: I5ce176538a53136aff3eea4af04b762ac9a5a994
Reviewed-on: https://boringssl-review.googlesource.com/31044
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>
We broke this a while back and nothing noticed. (Note dereference just
above.) Therefore I guess we don't need to support it.
Change-Id: I501d43825e89acb5f7f13998541dc8ff59452a99
Reviewed-on: https://boringssl-review.googlesource.com/31144
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>
Bug: None
Change-Id: I01ea2bb0508b018e219ecc94108e6a4fbe247984
Reviewed-on: https://boringssl-review.googlesource.com/31124
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>
Change-Id: I2d1671a4f21a602191fd0c9b932244a376ac5713
Reviewed-on: https://boringssl-review.googlesource.com/31104
Reviewed-by: David Benjamin <davidben@google.com>
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>
Imported from upstream's 0971432f6f6d8b40d797133621809bd31eb7bf4e and
7d4c97add12cfa5d4589880b09d6139c3203e2f4, but with missing tests added. Along
the way, make Bytes work with any Span<const uint8_t>-convertable type.
Change-Id: If365f981fe8a8274e12000309ffd99b1bb719842
Reviewed-on: https://boringssl-review.googlesource.com/31086
Reviewed-by: Adam Langley <agl@google.com>
Historically, OpenSSL's modular exponentiation functions tolerated negative
moduli by ignoring the sign bit. The special case for a modulus of 1 should do
the same. That said, this is ridiculous and the only reason I'm importing this
is BN_abs_is_word(1) is marginally more efficient than BN_is_one() and we
haven't gotten around to enforcing positive moduli yet.
Thanks to Guido Vranken and OSSFuzz for finding this issue and reporting to
OpenSSL.
(Imported from upstream's 235119f015e46a74040b78b10fd6e954f7f07774.)
Change-Id: I526889dfbe2356753aa1e6ecfd3aa3dc3a8cd2b8
Reviewed-on: https://boringssl-review.googlesource.com/31085
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This fixes uninitialized memory read reported by Nick Mathewson in
https://github.com/openssl/openssl/issues/6347.
It imports the memset from upstream's 2c739f72e5236a8e0c351c00047c77083dcdb77f,
but I believe that fix is incorrect and instead RC4 shouldn't be allowed in
this context. See
https://github.com/openssl/openssl/pull/6603#issuecomment-413066462 for
details.
Update-Note: Decoding a password-protected PEM block with RC4 will, rather than
derive garbage from uninitialized memory, simply fail. Trying to encode a
password-protect PEM block with an unsupported cipher will also fail, rather
than output garbage (e.g. tag-less AES-GCM).
Change-Id: Ib7e23dbf5514f0a523730926daad3c0bdb989417
Reviewed-on: https://boringssl-review.googlesource.com/31084
Reviewed-by: Adam Langley <agl@google.com>
This imports upstream's be4e1f79f631e49c76d02fe4644b52f907c374b2.
Change-Id: If0c4f066ba0ce540beaddd6a3e2540165d949dd2
Reviewed-on: https://boringssl-review.googlesource.com/31024
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>
- Document failure conditions of EVP_MD_CTX_copy_ex,
EVP_DigestInit_ex, HMAC_Init_ex, and CBB_init
Change-Id: I643d1b92e88e7f690fa555f7d908317a23e5cd95
Reviewed-on: https://boringssl-review.googlesource.com/30964
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>
