This reverts commit c1c9c2221ef26c7cb808ffe79dad4217bd7f431b.
I am looking at improving the API in a different way, so I'm undoing
this change to reduce churn in the interim.
The "Submodules and file naming" section ended with three backticks (` ``` `), which caused the next section to be unformatted instead of using proper Markdown formatting.
Run on Rust stable.
Install C++ compiler and other Kcov dependencies.
Don't install sources and packages that are not needed.
Update Kcov to the latest version.
I agree to license my contributions to each file under the terms given
at the top of each file I changed.
Removed unnecessary `sudo` entries.
Make `distro` explicit in case we want to mix Linux build environments.
Adjust compiler packages to the correct defaults.
I agree to license my contributions to each file under the terms given
at the top of each file I changed.
`num >= 4` is not the same as `num & ~3`. This is pretty much a no-op
change because we expect that we'll never encounter a situation where
`num` is too large to be represented as a 32-bit integer.
This will ensure that this code is tested in CI and is being compiled
by MSVC; previously this C code wasn't being tested at all because all
platforms we use for testing were taking other code paths.
The GHASH part of the tag was effectively being truncated to 16 bits
each round because of a type confusion error. Prior to commit
c4e76592fb2983cd17d20882bf391377b9c44395, the `Xi` parameter of
`GFp_gcm_ghash_4bit` was `uint64_t Xi[2]` and it worked correctly.
In c4e76592fb2983cd17d20882bf391377b9c44395 the type was changed to
`uint8_t Xi[16]`. Most of the code was adapted to the new type,
except these two lines. In particular, note that in that commit that
`GFp_gcm_gmult_4bit` did have the same change made to it.
This only affects AAarch64 platforms without PMULL. X86, X86_64,
and 32-bit ARM have only assembly language code for GCM that is used
instead, so they are unaffected. AAarch64 platforms with PMULL, e.g.
most phones, are not affected because they will use the PMULL-based
code. Consequently, this code wasn't being tested in CI or in most
other configurations.
The C compilers didn't catch this because Clang and GCC do not enable
`-Wconversion` even when `-Wextra` is provided, and because this code
is never compiled with MSVC. A future commit will change both of these
aspects. I verified that MSVC 2017 catches this bug immediately as soon
as allow it to be compiled for X86_64.
Unfortunately, this requires partially reverting
https://boringssl-review.googlesource.com/31324. This is a mess.
While clang proper includes a fuzzer driver, Chromium doesn't use it.
Chromium builds exclusively with fuzzer-no-link and links to its own
copy of the fuzzer runtime[1]. As of [2], Chromium's clang (which we use
on bots) no longer includes the driver, so we must mimic them.
However, Chromium's setup is somewhat questionable because
fuzzer-no-link pulls in libclang_rt.fuzzer_no_main which still includes
most of libclang_rt.fuzzer, just not the one main function[3]. It
appears Chromium is actually linking two copies of
libclang_rt.fuzzer_no_main. Hopefully this mostly works out as Chromium's
clang and libFuzzer should be relatively aligned, but it's not a good
assumption for our build, which can take other Clangs too.
Thus, if you pass -DFUZZ=1 as-is, we will assume you are using a
"normal" Clang with all its relevant runtimes intact. If, however, you
are using Chromium clang, you must drop the matching libFuzzer where the
bots expected it and build with -DLIBFUZZER_FROM_DEPS=1.
This involves no changes to the bots because we never actually unwound
all the LIBFUZZER_FROM_DEPS bits before.
[1] https://cs.chromium.org/chromium/src/testing/libfuzzer/BUILD.gn?rcl=d21c49585f262e851e2984f96f52905782706325&l=14
[2] c79bf2ea4c
[3] 8ebc3668b0/lib/fuzzer/CMakeLists.txt (L93-L107)8ebc3668b0/lib/fuzzer/FuzzerMain.cpp
Change-Id: I946b3c821c3d7e6def7e07f1381f58241611ba3d
Reviewed-on: https://boringssl-review.googlesource.com/c/34184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
MakeConstSpan() takes size_t as the second argument, so protos_len ought to also be size_t.
Bug: chromium:879657
Change-Id: I93089ea20ce4b9c2b9d4d954dce807feb5341482
Reviewed-on: https://boringssl-review.googlesource.com/c/34164
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This requires the addition of a constructor for aead::nonce::Iv from
an aead::block::Block.
I agree to license my contributions to each file under the terms given
at the top of each file I changed.
This adds a new API to the AEAD module for generating QUIC Header Protection
masks, as described in draft-ietf-quic-tls-17.
Only AES support is currently implemented, but ChaCha20 can be added later.
I agree to license my contributions to each file under the terms given
at the top of each file I changed.
