Delocate failed with some versions of Clang that reference
OPENSSL_ia32cap_P with an orq instruction.
Change-Id: I448d291594f5f147424e6f7014a681c4201b0aee
Reviewed-on: https://boringssl-review.googlesource.com/29764
Reviewed-by: Adam Langley <alangley@gmail.com>
With SSL 3.0 gone, there's no need to split up MD5 and SHA-1.
Change-Id: Ia4236c738dfa6743f1028c2d53761c95cba96288
Reviewed-on: https://boringssl-review.googlesource.com/29744
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>
Change-Id: Id7f5ef9932c4c491bd15085e3c604ebfcf259b7c
Reviewed-on: https://boringssl-review.googlesource.com/29665
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>
Change-Id: I436cc772eb975ad989035ee154a2e050c65e2961
Reviewed-on: https://boringssl-review.googlesource.com/29664
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 f2bc5f4 davidben pointed out that this function seems unnecessary
in my desired end-state. In fact, I think it may have been
unnecessary since 56986f90. (This was easier to miss at the time,
since at the time the function was part of MoveExData(), having not
yet been factored out.)
Change-Id: Ia9b4a909c93cb595666bcf7356a9f9a085901455
Reviewed-on: https://boringssl-review.googlesource.com/29604
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>
Previously we used thread-local state objects in rand.c. However, for
applications with large numbers of threads, this can lead to excessive
memory usage.
This change causes us to maintain a mutex-protected pool of state
objects where the size of the pool equals the maximum concurrency of
|RAND_bytes|. This might lead to state objects bouncing between CPUs
more often, but should help the memory usage problem.
Change-Id: Ie83763d3bc139e64ac17bf7e015ad082b2f8a81a
Reviewed-on: https://boringssl-review.googlesource.com/29565
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>
While I'm here, remove the silly "tlsext_" prefix. At this point it's no
longer novel that a feature is encoded in an extension.
Change-Id: Ib5fbd2121333a213bdda0332885a8c90036ebc4d
Reviewed-on: https://boringssl-review.googlesource.com/29592
Reviewed-by: Adam Langley <agl@google.com>
This doesn't actually make use of much of C++ yet. (SSL_CTX and
SSL/SSL_CONFIG carry analogous versions of a number of fields. It's
difficult to switch them to UniquePtr separately.)
Change-Id: Ia948f539c5c90e2d8301193f719604a31be17fc4
Reviewed-on: https://boringssl-review.googlesource.com/29589
Reviewed-by: Adam Langley <agl@google.com>
This doesn't give them a destructor yet, just shifts things around. In
doing so, it reveals that we inconsistently allowed internal code, but
not external code, to call functions like bssl::SSL_CTX_set_handoff_mode
without a namespace because of ADL. External code doesn't get to do
this because it doesn't see that ssl_ctx_st has a base class in
namespace bssl.
Change-Id: I2ab3b00fff2d6369e850606eed63017e4f8cf8c4
Reviewed-on: https://boringssl-review.googlesource.com/29588
Reviewed-by: Adam Langley <agl@google.com>
It's 2018, but passing STL objects across the API boundary turns out to
still be more bother than it's worth. Since we're dropping UniquePtr in
the API anyway, go the whole way and make it a plain-C API.
Change-Id: Ic0202012e5d81afe62d71b3fb57e6a27a8f63c65
Update-note: this will need corresponding changes to the internal use of SSL_CTX_add_cert_compression_alg.
Reviewed-on: https://boringssl-review.googlesource.com/29564
Reviewed-by: David Benjamin <davidben@google.com>
To wit, |RetryAsync| and |CheckIdempotentError|.
This helps with creating a separate binary to perform split
handshakes.
Separate handshake utilities
Change-Id: I81d0bc38f58e7e1a92b58bf09407452b345213b4
Reviewed-on: https://boringssl-review.googlesource.com/29346
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>
This makes |TestState| and |TestConfig| accessible outside
bssl_shim.cc, as well as the functions SetupCtx() and NewSSL(), which
become methods on |TestConfig|. A whole mess of callbacks move in
order to support this change.
Along the way, some bits of global state are moved (e.g. the global
test clock) and made self-initializing.
This helps with creating a separate binary to perform split
handshakes.
Change-Id: I39b00a1819074882353f5f04ed01312916f3cccb
Reviewed-on: https://boringssl-review.googlesource.com/29345
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>
Previously we'd partially attempted the ssl_st / bssl::SSLConnection
subclassing split, but that gets messy when we actually try to add a
destructor, because CRYPTO_EX_DATA's cleanup function needs an ssl_st*,
not a bssl::SSLConnection*. Downcasting is technically undefined at this
point and will likely offend some CFI-like check.
Moreover, it appears that even with today's subclassing split,
New<SSL>() emits symbols like:
W ssl_st*& std::forward<ssl_st*&>(std::remove_reference<ssl_st*&>::type&)
The compiler does not bother emitting them in optimized builds, but it
does suggest we can't really avoid claiming the ssl_st type name at the
symbol level, short of doing reinterpret_casts at all API boundaries.
And, of course, we've already long claimed it at the #include level.
So I've just left this defining directly on ssl_session_st. The cost is
we need to write some silly "bssl::" prefixes in the headers, but so it
goes. In the likely event we change our minds again, we can always
revise this.
Change-Id: Ieb429e8eaabe7c2961ef7f8d9234fb71f19a5e2a
Reviewed-on: https://boringssl-review.googlesource.com/29587
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>
lh_FOO_retrieve is often called with a dummy instance of FOO that has
only a few fields filled in. This works fine for C, but a C++
SSL_SESSION with destructors is a bit more of a nuisance here.
Instead, teach LHASH to allow queries by some external key type. This
avoids stack-allocating SSL_SESSION. Along the way, fix the
make_macros.sh script.
Change-Id: Ie0b482d4ffe1027049d49db63274c7c17f9398fa
Reviewed-on: https://boringssl-review.googlesource.com/29586
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 partitions the session ID space of the internal cache by version,
which is nominally something we want, but we must check the version
externally anyway for both tickets and external session cache. That
makes this measure redundant. (Servers generate session IDs and 2^256 is
huge, so there would never accidentally be a collision.)
This cuts down on the "key" in the internal session cache, which will
simplify adding something like an lh_SSL_SESSION_retrieve_key function.
(LHASH is currently lax about keys because it can freely stack-allocate
partially-initialized structs. C++ is a bit more finicky about this.)
Change-Id: I656fd9dbf023dccb163d2e8049eff8f1f9a0e21b
Reviewed-on: https://boringssl-review.googlesource.com/29585
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>
We have generic -on-resume prefixes now. This avoids the global counter.
Change-Id: I7596ed3273e826b744d8545f7ed2bdd5e9190958
Reviewed-on: https://boringssl-review.googlesource.com/29594
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Matt Braithwaite <mab@google.com>
bssl::UniquePtr and FOO_up_ref do not play well together. Add a helper
to simplify this. This allows us to write things like:
foo->cert = UpRef(bar->cert);
instead of:
if (bar->cert) {
X509_up_ref(bar->cert.get());
}
foo->cert.reset(bar->cert.get());
This also plays well with PushToStack. To append something to a stack
while taking a reference, it's just:
PushToStack(certs, UpRef(cert))
Change-Id: I99ae8de22b837588a2d8ffb58f86edc1d03ed46a
Reviewed-on: https://boringssl-review.googlesource.com/29584
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>
alignas in C++11 is a bit more flexible than
__attribute__((aligned(x))), and we already require C++11 in tests.
Change-Id: If61c35daa5fcaaca5119dcc6808a3e746befc170
Reviewed-on: https://boringssl-review.googlesource.com/29544
Reviewed-by: Adam Langley <agl@google.com>
Fewer things we need to update as the internals change.
Change-Id: If615a56557c8acbe08501f091e9fe21e5ff8072c
Reviewed-on: https://boringssl-review.googlesource.com/29525
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>
This helps with creating a separate binary to perform split
handshakes.
Change-Id: Ie4bab40bebf39e79a90d45fabb566b7ce90945bb
Reviewed-on: https://boringssl-review.googlesource.com/29344
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>
The whitespace in the _STL_EXTRA_DISABLED_WARNINGS value was creating issues
for the CMake generated assembler build script called by VS.
By narrowing the build scope of this STL (and thus C++ only) variable to only C++
we avoid the problem altogether as it will not be passed to the assembler script.
Change-Id: Id422bdd991492f39acc82d52af2ea6d952deb6c6
Reviewed-on: https://boringssl-review.googlesource.com/29504
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>
It's 2018. I'm not sure why I added the 32-bit ones; even the 32-bit
bots build and run on 64-bit Windows. ninja.exe in depot_tools is also a
64-bit binary. I suspect this is because some of the depot_tools bits
use --platform=win32, but that's just the sys.platform string.
Alas, I stupidly named these "win32" way back. Dealing with the rename
is probably more trouble than worth it right now since the build recipes
refer to the name. Something to deal with later. (Regardless we'll want
"win32" to point to 64-bit binaries so that try jobs can test it.)
Also add the missing nasm-win32.exe to .gitignore.
For some reason the 64-bit Yasm binary does not work on the vs2017 CQ
bots, so I've left it alone. Hopefully it should be replaced by NASM
later anyway.
Change-Id: If65ececddbc6526ceebaafbef56eddea8ece58ba
Reviewed-on: https://boringssl-review.googlesource.com/29384
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>
We don't support SSL3 at all now. Actually we haven't supported renego
SSL3 in even longer, so this was false even before yesterday.
Change-Id: Ie759477fa84099dd486c4c4604080ecf8ecdf434
Reviewed-on: https://boringssl-review.googlesource.com/29484
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change moves to the final version of zx_cprng_draw, which cannot
fail. If the syscall would fail, either the operating system terminates
or the kernel kills the userspace process (depending on where the error
comes from).
Change-Id: Iea9563c9f63ea5802e2cde741879fa58c19028f4
Reviewed-on: https://boringssl-review.googlesource.com/29424
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 was changed in draft-ietf-quic-tls-13 to use a codepoint from the
reserved range.
Change-Id: Ia3cda249a3f37bc244d5c8a7765ec34a5708c9ae
Reviewed-on: https://boringssl-review.googlesource.com/29464
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>
Update-Note: SSL_CTX_set_min_proto_version(SSL3_VERSION) now fails.
SSL_OP_NO_SSLv3 is now zero. Internal SSL3-specific "AEAD"s are gone.
Change-Id: I34edb160be40a5eea3e2e0fdea562c6e2adda229
Reviewed-on: https://boringssl-review.googlesource.com/29444
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 doesn't particularly matter since most clients don't typically
advertise both versions, but we should presumably prefer the newer one.
Change-Id: If636e446c6af2049fc5743eb5fef04b780b29af9
Reviewed-on: https://boringssl-review.googlesource.com/29445
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>
The full library is a bit much, but this is enough to appease most of
cryptography.io.
Change-Id: I1bb0d83744c4550d5fe23c5c98cfd7e36b17fcc9
Reviewed-on: https://boringssl-review.googlesource.com/29365
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>
This is to transition BoringSSL's Windows build from Yasm to NASM. This
change itself is a no-op for now, but a later change to the BoringSSL
recipes will add a pair of standalone builders here. Then I'll get the
change I have lying around for Chromium moving.
Bug: chromium:766721
Change-Id: I4dca1c299f93bc5c01695983fe0478490c472deb
Reviewed-on: https://boringssl-review.googlesource.com/29324
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>
Right now we're inconsistent about it. If the OPTIONAL container is
missing, we report an error, but if the container is empty, we happily
return nothing. The latter behavior is more convenient for emulating
OpenSSL's PKCS#7 functions.
These are our own functions, so we have some leeway here. Looking
through callers, they appear to handle this fine.
Update-Note: This is a behavior change.
Change-Id: I1321025a64df3054d380003c90e57d9eb95e610f
Reviewed-on: https://boringssl-review.googlesource.com/29364
Reviewed-by: Adam Langley <agl@google.com>
CBS_asn1_ber_to_der was a little cumbersome to use. While it, in theory,
allowed callers to consistently advance past the element, no caller
actually did so consistently. Instead they would advance if conversion
happened, and not if it was already DER. For the PKCS7_* functions, this
was even caller-exposed.
Change-Id: I658d265df899bace9ba6616cb465f19c9e6c3534
Reviewed-on: https://boringssl-review.googlesource.com/29304
Reviewed-by: Adam Langley <agl@google.com>
Copy of OpenSSL change
80770da39e.
This additionally fixes some bugs which causes time validation to
fail when the current time and certificate timestamp are near the
2050 UTCTime/GeneralizedTime cut-off.
Update-Note: Some invalid X.509 timestamps will be newly rejected.
Change-Id: Ie131c61b6840c85bed974101f0a3188e7649059b
Reviewed-on: https://boringssl-review.googlesource.com/29125
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>
Previously, delocate.go couldn't handle GOT references and so |stderr|
was a problematic symbol. We can cope with them now, so write FIPS
power-on test and urandom errors to stderr rather than stdout.
Change-Id: If6d7c19ee5f22dcbd74fb01c231500c2e130e6f7
Update-note: resolves internal bug 110102292.
Reviewed-on: https://boringssl-review.googlesource.com/29244
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change adds an AES-GCM AEAD that enforces nonce uniqueness inside
the FIPS module, like we have for TLS 1.2. While TLS 1.3 has not yet
been mentioned in the FIPS 140 IG, we expect it to be in the next ~12
months and so are preparing for that.
Change-Id: I65a7d8196b08dc0033bdde5c844a73059da13d9e
Reviewed-on: https://boringssl-review.googlesource.com/29224
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>
I forgot about this file.
Change-Id: Icb98ffe3ed682a80d7a809a4585a5537fed0ba1c
Reviewed-on: https://boringssl-review.googlesource.com/29284
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>
cryptography.io gets offended if the library supports some OFB sizes but
not others.
Change-Id: I7fc7b12e7820547a82aae84d9418457389a482fe
Reviewed-on: https://boringssl-review.googlesource.com/29204
Reviewed-by: Adam Langley <agl@google.com>
The DSA code is deprecated and will, hopefully, be removed in the future.
Nonetheless, this is easy enough to fix. It's the analog of the work we'd
already done for ECDSA.
- Document more clearly that we don't care about the DSA code.
- Use the existing constant-time modular addition function rather than
the ad-hoc code.
- Reduce the digest to satisfy modular operations' invariants. (The
underlying algorithms could accept looser bounds, but we reduce for
simplicity.) There's no particular reason to do this in constant time,
but we have the code for it, so we may as well.
- This additionally adds a missing check that num_bits(q) is a multiple
of 8. We otherwise don't compute the right answer. Verification
already rejected all 160-, 224-, and 256-bit keys, and we only
generate DSA parameters where the length of q matches some hash
function's length, so this is unlikely to cause anyone trouble.
- Use Montgomery reduction to perform the modular multiplication. This
could be optimized to save a couple Montgomery reductions as in ECDSA,
but DSA is deprecated, so I haven't bothered optimizing this.
- The reduction from g^k (mod p) to r = g^k (mod p) (mod q) is left
in variable time, but reversing it would require a discrete log
anyway. (The corresponding ECDSA operation is much easier to make
constant-time due to Hasse's theorem, though that's actually still a
TODO. I need to finish lifting EC_FELEM up the stack.)
Thanks to Keegan Ryan from NCC Group for reporting the modular addition issue
(CVE-2018-0495). The remainder is stuff I noticed along the way.
Update-Note: See the num_bits(q) change.
Change-Id: I4f032b041e2aeb09f9737a39f178c24e6a7fa1cb
Reviewed-on: https://boringssl-review.googlesource.com/29145
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 reverts commit 43eb0af5f1.
Reason for revert: Hopefully this is resolved by https://boringssl.googlesource.com/boringssl/+/7c8e725e55a72c914eb3a33af6cc65b4188102c6 ?
Original change's description:
> Reland "Revert "Add other Windows configurations to the CQ.""
>
> This reverts commit 23e92d5d16.
>
> Reason for revert: Nope. Still doesn't work. Back to poking infra
> about it...
>
> Original change's description:
> > Revert "Revert "Add other Windows configurations to the CQ.""
> >
> > This reverts commit 98831738f2.
> >
> > Let's try this again. tandrii@ says this should be resolved as of
> > https://crbug.com/840505. (That was a while ago. I'd forgotten about
> > it.)
> >
> > Change-Id: Ib49a629198a33d44ff1c3aa13af5825def1a5c4d
> > Reviewed-on: https://boringssl-review.googlesource.com/28924
> > Reviewed-by: Steven Valdez <svaldez@google.com>
> > Commit-Queue: Steven Valdez <svaldez@google.com>
> > CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
>
> TBR=davidben@google.com,svaldez@google.com
>
> Change-Id: Iecd0710075f1fedc4dea69283d018042fb1a2490
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://boringssl-review.googlesource.com/29104
> 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>
TBR=davidben@google.com,svaldez@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I583641be42e6e6e93eb30adbe56ae20812608103
Reviewed-on: https://boringssl-review.googlesource.com/29184
Reviewed-by: David Benjamin <davidben@google.com>
Although the original value of tmp does not matter, the selects
ultimately do bit operations on the uninitialized values and thus depend
on them behaving like *some* consistent concrete value. The C spec
appears to allow uninitialized values to resolve to trap
representations, which means this isn't quite valid..
(If I'm reading it wrong and the compiler must behave as if there were a
consistent value in there, it's probably fine, but there's no sense in
risking compiler bugs on a subtle corner of things.)
Change-Id: Id4547b0ec702414b387e906c4de55595e6214ddb
Reviewed-on: https://boringssl-review.googlesource.com/29124
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>
This version doesn't have short reads. We'll eventually rename the
syscall back to zx_cprng_draw once all the clients have migrated to the
new semantics.
Change-Id: I7a7f6751e4d85dcc9b0a03a533dd93f3cbee277f
Reviewed-on: https://boringssl-review.googlesource.com/29084
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 reverts commit 23e92d5d16.
Reason for revert: Nope. Still doesn't work. Back to poking infra
about it...
Original change's description:
> Revert "Revert "Add other Windows configurations to the CQ.""
>
> This reverts commit 98831738f2.
>
> Let's try this again. tandrii@ says this should be resolved as of
> https://crbug.com/840505. (That was a while ago. I'd forgotten about
> it.)
>
> Change-Id: Ib49a629198a33d44ff1c3aa13af5825def1a5c4d
> Reviewed-on: https://boringssl-review.googlesource.com/28924
> Reviewed-by: Steven Valdez <svaldez@google.com>
> Commit-Queue: Steven Valdez <svaldez@google.com>
> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
TBR=davidben@google.com,svaldez@google.com
Change-Id: Iecd0710075f1fedc4dea69283d018042fb1a2490
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://boringssl-review.googlesource.com/29104
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>
