It's only used from that file and, given the names defined by it,
probably isn't usable by other files anyway.
Change-Id: Ice205408962ade00c1dcb51406da3ef2fd7f0393
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46426
Reviewed-by: Adam Langley <agl@google.com>
We have loads of variations of these. Align them in one set. This avoids
the HOST_* macros defined by md32_common.h, so it'll be a little easier
to make it a more conventional header.
Change-Id: Id47fe7b51a8f961bd87839f8146d8a5aa8027aa6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46425
Reviewed-by: Adam Langley <agl@google.com>
It's a little confusing to have load_word_le but actually use size_t
instead of crypto_word_t.
NOTE: on some platforms, notably NaCl, crypto_word_t is larger than
size_t. (Do we still need to support this?) We don't have a good testing
story here, so I tested it by hacking up a 32-bit x86 build to think it
was OPENSSL_64_BIT.
Change-Id: Ia0ce469e86803f22655fe2d9659a6a5db766429f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46424
Reviewed-by: Adam Langley <agl@google.com>
Some of our calls handled it and others didn't.
Change-Id: I09f15d3db679954599bcf987d86357b6e12e9b9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46532
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The ssl_buffer.cc code handles this, but since outgoing handshake I/O
goes through a different path, it was missing these checks.
Change-Id: I4fed62b435b577645c405d0d995511a58d47a702
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46531
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The check for ssl_hs_read_change_cipher_spec didn't do anything. Replace
it with an assert and add some comments since the hs->wait handling is a
little tricky.
Change-Id: I8e62ce3cceca9bed4611cb9d3faf0bfec3d3bdd4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46530
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It's strange to have Serialize/Deserialize methods not inverses of each
other. Split the operation up and move the common parts out of the
subclass.
Change-Id: Iadfa57de19faca411c64b64d2568a78d2eb982e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46529
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The delegated credentials bits got stuck in the middle of the handshake
bits.
Change-Id: I522d8a5a5f000de3e329934851ee74fc4ec613a7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46528
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
TLS 1.3 works, so no need to exclude version negotiation. We also now
only test QUICTransportParams with QUIC, so there is no need to exclude
it manually. Checking the protocol works as well.
Change-Id: Ie9d33095231a1f9eb74145db5147a287e4fdc930
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46527
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is no longer needed.
Change-Id: Ie6dba524ecccd265f7f80a910b40c0fe1800356b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46526
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Do a better job with scopers for fds and posix_spawn_file_actions_t.
There's also no need to make a copy of handshaker_path with strdup.
The non-const parameter are because posix_spawn inherits execve's
C problem: unlike C++, C cannot cast from char *const * to
const char *const *, so POSIX APIs are not const-correct.
Finally, we freely use std::vector and friends in tests, so we don't
actually need to depend on bssl::Array.
Change-Id: I739dcb6b1a2d415d47ff9b2399eebec987aab0bc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46524
Reviewed-by: Adam Langley <agl@google.com>
When doing Android FIPS validations one ends up with quite a lot of
different build configurations for ACVP and it's useful to be able to
check that a binary is what you think it is.
Change-Id: Ie5c81f164e6e6903c85ea832a93868f84921e74a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46484
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Omitting the extension means we'll never issue tickets, but if the
client were to offer a ticket anyway, RFC8446 4.2.9 says we MUST reject
the ClientHello. It's not clear on what alert to use, but
missing_extension is probably appropriate.
Thanks to Ben Kaduk for pointing this out.
Change-Id: Ie5c720eac9dd2e1a27ba8a13c59b707c109eaa4e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46464
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
MSAN doesn't like the counters starting at whatever value malloc
found to be free.
Change-Id: I0968e61e0025db35b82291fde5d1e193aef77c1e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46444
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This wasn't being used and wasn't even set correctly in split handshake
tests.
Change-Id: I03000db8dd3c227ea44e7bacaf3d1341259fae44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46384
Reviewed-by: Adam Langley <agl@google.com>
It's now a year past the February 2020 deadline for removing it. Judging
from b/72831885, it looks like the root cause was addressed.
Change-Id: I8c8b358ef4f4146b41aab2a7163c000fa7306025
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46407
Reviewed-by: Adam Langley <agl@google.com>
Although it is strictly fine to call SHA512_Final in SHA384_Final
(array sizes in C parameters are purely decorational, according to the
language), GCC 11 reportedly checks now and gets upset about the size
mismatch. Use an unsized helper function so all our code matches the
specified bounds.
Unfortunately, the bounds in all the functions are a bit misleading
because SHA512_Final really outputs based on sha->md_len (which Init
function you called) rather than which Final function. I've fixed this
places within a library where we mismatched and added asserts to the
smaller functions. SHA512_Final is assert-less because I've seen lots of
code use SHA384_Init / SHA512_Update / SHA512_Final.
This doesn't fix the SHA256 variant since that is generated by a pile of
macros in a multiply-included file. This is probably a good opportunity
to make that code less macro-heavy.
Update-Note: There is a small chance the asserts will trip something,
but hopefully not since I've left SHA512_Final alone.
Bug: 402
Change-Id: I4c9d579a63ee0a0dea103c19ef219c13bb9aa62c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46405
Reviewed-by: Adam Langley <agl@google.com>
The compiler complained that `words` is never read in situations where
it is passed to the assembly code as a `Key`, relying on `Key` being
`#[repr(transparent)]`.
We've been moving away from using `repr(transparent)` for these kinds of types. Do
that here to solve this problem and also to continue that general trend. Use
`words_less_safe()` instead of directly accessing `words` to reduce the amount of
conditional logic.
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>
It's now 2021. Hopefully we can at least assume anyone building with
-std=c11 also has a corresponding set of headers. Plus, even if you
don't, Clang seems to provide a header. (So C11 atomics work in
clang-cl.) Also apparently atomics are optional, so this checks
__STDC_NO_ATOMICS__.
This does *not* set C11 as the minimum version. If you build with
-std=c99, we'll silently use the non-atomics implementation. That's a
little magical, so I've kept OPENSSL_C11_ATOMIC as a way to assert that
you really want C11 atomics. Mostly it turns into a -std=c11 && !MSVC
self-assert.
Update-Note: If something fails to compile, we'll revert this and adjust
the check, or add an opt-out, or give up. Also, if building with
-std=c99, consider -std=c11.
Change-Id: I1a8074c367a765c5a0f087db8c250e050df2dde8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46344
Reviewed-by: Adam Langley <agl@google.com>
To make the script run with python3, let me replace python2 specific
dict functions to python3 compatible ones.
Change-Id: I85b446234f9a86a02f60eed311e1c747a3ff399b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46364
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
