This change also adds scoped.rs, which contains scoped objects for
`EVP_PKEY` and `EC_KEY`, for when we're holding temporary objects of
those types.
Due to an accident with git rebase, it also renames `crypto_memcmp` to
`constant_time_compare` and promotes it to the top-level of the crate.
Change-Id: I629c051a244e3f9dcf64d8a36846528f10a31f50
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65174
Reviewed-by: Bob Beck <bbe@google.com>
This function took a `c_int` and checked that it was 1. But since
`initialized_struct_fallible` now expects a bool, this should too.
Change-Id: Ice7997c0847299f42fbc71fcc7b29acb66014bde
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65547
Reviewed-by: Bob Beck <bbe@google.com>
I'll also group them with hash-dir functions later, but it's worth
clarifying this inline.
Change-Id: Ia9166dd75d2546f8f2e5cf627823ec7206cf9fdc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65427
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
2048 is too high, particularly in heavily instrumented fuzzer builds
with large stack frames. Use a much more conservative limit.
Change-Id: If0b49f2ca04520c41400dcbfd83463766fded3a9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65508
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
When BER was nested deep inside otherwise valid DER, cbs_find_ber's
internally book-keeping would clobber *out_ber_found and lose track that
there was some BER to convert.
This is unlikely to come up in real world inputs, as the only reason to
use any of these awful BER features is to stream the output. I.e., there
is no reason to have indefinite-length inside definite-length, and there
is no reason to have definite-length constructed string. That means
cbs_find_ber, realistically, can just check for indefinite-length
encoding at the front and do nothing else.
Nonetheless, these inputs are nominally allowed, so fix the book-keeping
bug.
Change-Id: Idaf3c178fa511ce24af83d6ae27fa9f197f1789e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65507
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Sections are stored in a CONF structure as having name == NULL and value
being a STACK_OF(CONF_VALUE) with the wrong pointer type. This loses
type safety and complicates all the cleanup functions. (E.g.
crypto/x509 has its own X509V3_conf_free which is distinct from the copy
in crypto/conf.c.)
These objects are, happily, never exported outside the file. Replace
them with a CONF_SECTION and store the two values in separate hash
tables. This also means a CONF_VALUE's name is no longer nullable, so
all the comparisons and hashes become simpler.
Also fix up add_string slightly. It left the CONF in a slightly
precarious state if a malloc failed in the middle. Also v->section
would leak if add_string failed.
Change-Id: Ib54e9dd5037766804c8ddcd80d357237d2d357ea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60106
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Also move EC_GROUP_free and EC_GROUP_dup to the deprecated section,
because it's now usually unnecessary.
Change-Id: Ica4aa8d2b993555f977792bf284a5dbf29a3d710
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63245
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The sources of bssl_crypto, at least, are non-trivial and it'll
otherwise be a pain to keep them in sync.
Change-Id: I879f691cc8870a2215345e7c8900d98c6ae45f37
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65487
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Change-Id: I3549fb623db267df5956c9412d758749abd2a4dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65468
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Use equivalent but simpler math, and explain the simpler math. Move the
discussion of multipying-vs-doubling to be after the discussion of
squaring-vs-doubling so that the discussion order follows the code
order, and so that we can combine the multipying-vs-doubling discussion
with the explanation of why no multiply/doubling is needed at all.
Expand the existing discussion to be a little more explicit.
Retain |threshold|, but change the type of |threshold| was changed to
|int| to avoid a signed/unsigned comparison in the added assertion
(|bn_mod_lshift_consttime| takes the shift count as an |int| anyway).
Change-Id: I24e4687e76944a34a8621b5f2fdee15a5201ac88
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63906
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Change-Id: Ib92b2ae60b12cf6b854ebce8273c3b10272e61bd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65028
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/64208 caused us
to skip the runtime check for SHA extensions when SHA is statically
available. This change was correct (though we don't get the size wins
without also emulating -ffunction-sections in the asm file), but we've
run into a few places where projects build with -march=goldmont, but
need a build that does not require SHA extensions:
- Some CrOS toolchain definitions are incorrect and build with
-march=goldmont when targetting boards that are not Goldmont. b/320482539
tracks fixing this.
- Sometimes projects build with -march=goldmont as a rough optimized
baseline. However, Intel CPU capabilities are not strictly linear, so
this does not quite work. Some combination of -mtune and
-march=x86-64-v{1,2,3,4} would be a better strategy here.
- QEMU versions before 8.2 do not support SHA extensions and disable it
with a warning. Projects that target Goldmont and test on QEMU will
break. The long-term fix is to update to 8.2. A principled short-term fix
would be -march=goldmont -mno-sha, to reflect that the binary needs to
run on both QEMU-8.1-Goldmont and actual-Goldmont.
Other than the CrOS issue, the others have been resolved or at least
worked around, so once the CrOS issue is fixed, and the changes made
their way through the pipeline, we can try this again. Though with the
QEMU issue, the longer we wait, the less likely we'll trip people
running old QEMUs.
Bug: b:320482539
Change-Id: Iab30a441fce313a1413a465f88d7d52cde179292
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65407
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Mostly to silence complaints about x/crypto, but we don't use the ssh
package so it doesn't really matter.
Change-Id: Ieaae4727cb34417fbf5ed47068b46074c0881de0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65027
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
These were flagged when patching the PRNG to return data marked secret.
This CL doesn't include that part (I didn't run all tests, and other
tests likely require further annotations), but it does include some of
the declassifications necessary to do that later.
Broadly:
- Whenever we compute public keys from private keys, we must tell
valgrind the public key is now public. (Valgrind does not know
that cryptography works.)
- Whenever we compute signatures from private keys, we must tell
valgrind the signature is now public. (Ditto.)
- Whenever we pass a secret value but check it is fully reduced, we must
tell valgrind the comparison may be leaked. (Valgrind doesn't know
these values are always within range... that we have to check at all
is a consequence of OpenSSL's API and/or defensive coding.)
- Valgrind does not know about the randomizing properties of blinding.
We actually aim to be constant-time without RSA blinding, so that
doesn't need an annotation, but the blinded inversion step in the
process of computing the RSA blinding factor does.
Bug: 676
Change-Id: Ic3a47adddb23a61fe452b9be27b214eec2ea5235
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65367
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
If BORINGSSL_FIPS is defined, then rand_thread_state_free will attempt to manage the next and prev
pointers. These will be set to undefined values in the case of CRYPTO_set_thread_local calling rand_thread_state_free,
as theese pointers are not initalized until later on.
Change-Id: Ie7712e7eb4acec7cca6890cfabc2030f18ab5244
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63885
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
strongswan defines conflicting symbols and has been relying on them only
being defined in <openssl/x509v3.h>. Defining the constants in
<openssl/x509.h> would break strongswan, so move them back for now.
Long term, we would like for new code to only need <openssl/x509.h>, so
I've left a TODO to introduce properly namespaced versions of these
constants and, separately, see if we can fix strongswan to similarly
avoid the conflict. Between OpenSSL, strongswan, and wincrypt.h all
defining these constants, it seems best for everyone to just avoid them
going forward.
Change-Id: I23ce4c5013a80a831e0dc74fda8623027017190c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65387
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is mostly what was used already, but not uniformly. This change
is exactly the result of running `cargo fmt` with the included
.rustfmt.toml.
Change-Id: Ib85687edffeecfb64938f556e54beb263f0b1d13
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65169
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Change-Id: Ib9fc874e1c5d540dda91a454681dad809e8d6d14
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65167
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Maurice Lam <yukl@google.com>
Reviewed-by: Nabil Wadih <nwadih@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
google3 is unhappy with this and needs some more love on where
the adr target gets placed to fit.
This reverts commit 62f43f5ea5.
Change-Id: I1e335c635590fdda72a8a98314a1640d5b7ea179
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65328
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
AES-GCM where the module generates the nonce itself is more directly
approved by FIPS. ACVP that instead of AES-GCM with an external nonce,
where compliance depends on a careful reading of the IG.
Change-Id: I8a3e926a28ae633a0b0c499cb35c321ccf9c0e30
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65227
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The x86-64 and x86 code both have 4x and 1x SSSE3 code paths. Only
the x86-64 version is modified here.
(For 32-bit x86, it looks like it would be much harder to separate
the 1x and 4x code paths into separate functions and there's
little motivation to do so. So it is likely that 32-bit x86 would
define |CHACHA20_ASM_SSSE3| without |CHACHA20_ASM_SSSE3_4X|.)
Bug: 673
Change-Id: I48a3fb8a2c6eb05a33c5ef20efff7ed000e51d71
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64467
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
On some AMD processors, we will act as if the hardware is
RDRAND-incapable, even it actually supports it, to workaround some bugs
where their RDRAND would return all ones. However, this works by
clearing the RDRAND bit, and the static capability check bypasses this.
That means, when compiling binaries for an RDRAND-capable baseline CPU,
we might end up disabling the workaround. Thanks to Brian Smith for
noticing this.
Fortunately, we believe this had no real impact and the workaround was
actually redundant with other parts of our PRNG logic. See
https://crbug.com/boringssl/675#c2 for a more detailed analysis.
Fixed: 675
Change-Id: I91d844cfaafb22eb29254f81fb6719588937a4a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65267
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Of external callers of this function, almost all are not actually doing
anything with this operation and are just trying to trigger
x509v3_cache_extensions. Triggering that is no longer necessarily now
that the structure is opaque and accessors do it for you.
There were three callers that wanted the actual operation here. One of
them correctly handled the tri-state return, but did not distinguish 0
from -1. The other two did not and would misinterpret -1 as success! So
this change is actually more compatible with OpenSSL callers than
OpenSSL's actual behavior.
Change-Id: Ifedba52dd9d4e031fc919276fd08ec22cfd33bf2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65153
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Test CRL handling, leave a TODO for bug 600, and also test that one can
add to an X509_STORE while verifying, as that's meant to work.
As part of this, I refreshed the test CRL so the sort wasn't degenerate.
When I inject a bug in generating the sorted CRL, TSan still only
flakily notices, but it does eventually notice.
Bug: 600
Change-Id: I0ae92651dcac9971b034cf9f1c127e9a25332bf5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65152
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CrOS EC and Zephyr build "emulation" targets that run in Linux
userspace. Although running on Linux, we want boringssl to run the same
as if it were running on the embedded target.
BUG=b/273639386
Change-Id: Id5f13391f09889e955d2a86e2c5317903b2a8bd6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65182
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Tom Hughes <tomhughes@chromium.org>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These are unused and are the only options that remove the "compat"
self-signed fallback.
X509_TRUST_OCSP_REQUEST was intended for checking signed OCSP requests.
While OpenSSL's OCSP implementation (which we've dropped) does attempt
to configure it, it actually does nothing. They call
X509_STORE_CTX_set_trust after X509_STORE_CTX_set_purpose, but
X509_STORE_CTX_set_purpose already sets the trust parameter and
X509_STORE_CTX_set_trust only acts when trust is not configured.
X509_TRUST_OCSP_SIGN was briefly used in upstream's
30c278aa6bb614f4cfc5a26c7cbe66ad090f6896, by way of
X509_PURPOSE_OCSP_HELPER, but then immediately undone in
e9754726d236b74476cd0be5fa60acfef0c7024f.
Change-Id: I6d2cf9b88a6b013e74fe95cd88f94051111086df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65151
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These tables are small enough that a linear scan is fine. This is one
less thing we need to keep in sync, and means we can remove entries
without renumbering them.
Change-Id: If1a41397aac3917534529e7e704983489e266a0f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65150
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
In particular, deprecate get_crl and check_crl. Only gRPC uses them, and
does so incorrectly. It is impossible to implement those callbacks
correctly.
Also remove X509_STORE_CTX_set_cert. No one uses it, and it's redundant
with X509_STORE_CTX_init. We should remove X509_STORE_CTX_set_chain too,
but there are some callers to cleanup.
Bug: 426
Change-Id: I846f8292a5f5d6cc3b5d2a576bfaf86e9ea84bdc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65147
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
All callers I found seem to be compatible with this. Using the non-const
pointer isn't very useful because you cannot resize the value. Let's try
const-correcting it and we'll revert if it's too annoying to fix.
Update-Note: The above functions are now const-correct. Store the result
in a const pointer to avoid compatibility issues.
Change-Id: Id4a1c7223fbb333716906e20844bf8795118a8ea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65128
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This CL makes two changes. First, it removes the couple of places where
X509_verify_cert may return -1 and switches to our standard 0/1 return
convention. The only -1 cases were get_issuer returning < 0 and the
caller error cases at the top. It seems implausible that any caller
would care about the latter and the former is actually impossible.
get_issuer never returns < 0.
Second, OpenSSL's original implementation did not follow the usual
error-handling convention. The usual convention is that there's a
cleanup epilog, and a variable (usually called 'ret' or 'ok') that
stores the return value. This variable is initialized in the failure
case and may only be modified immediately before a goto or when falling
through to the epilog. This allows error conditions to simply 'goto err'
and rely on the variable's value.
X509_verify_cert instead overwrite 'ok' throughout the function, which
is tedious and error-prone. Fix this to follow the usual convention.
Also remove uses of this pattern when there isn't anything to cleanup.
As part of this cleanup, we fix a near miss: the three cert_self_signed
call sites did not correctly account for this non-standard pattern.
Fortunately (as demonstrated by existing unit tests), the first call
site is fine. The remainder are only called on "trusted" certificates
from the X509_STORE. An attacker with control over trust anchors already
controls certificate verification, so this is moot. Moreover, all such
certificates first go through get_issuer, which calls X509_check_issued,
which already handles EXFLAG_INVALID, so the error condition was
redundant.
Update-Note: X509_verify_cert no longer returns -1 on some error
conditions, only zero.
Change-Id: I88d5e845cd4cb8f48d5c5df6782bf6730c682642
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65067
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
If a verify_cb consistently returns -1, it would broadly get treated as
success, except the final call would leak into ok and come out of
X509_verify_cert and read as failure. Prevent this ambiguity by
requiring the return value be 0 or 1, and aborting otherwise.
Update-Note: If the verify callback returns anything other than 0 or 1,
X509_verify_cert will now crash in BSSL_CHECK. If this happens, fix the
callback to use the correct return value.
Change-Id: I0394e68febe9f22a42bcd5de8ea4f3a82b07c862
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65107
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
The -1 cases were all removed in
https://boringssl-review.googlesource.com/c/boringssl/+/8303, so we can
simplify things. This removes almost all cases where X509_verify_cert
could have returned -1.
As part of this, align the get_issuer and find_issuer calling
conventions. Also rename it to get_trusted_issuer to make it clearer
that this is only searches for trusted certs.
Change-Id: I586d037106bb74887738a342d222948db8e49d53
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65088
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
All this flag does is cause verify_cb to be called with ok=2 after
policy validation happens, breaking the otherwise strict 0/1 behavior of
the callback.
We can't quite remove the symbol because a lot of bindings libraries
wrap it without realizing what it does. But no one actually uses it,
because it's pretty useless. Since we now always (other than the
bad_chain thing) check policies and that happens last, this flag really
means "please call the verify callback an extra time at the end with
ok=2".
Update-Note: X509_V_FLAG_NOTIFY_POLICY is now a no-op. This is not
expected to impact anyone.
Change-Id: I892a872181d1c1836ef2533ac616edfb6b3b5836
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65087
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Nothing uses it, OpenSSL does not document it, and it does not seem to
be correctly filled in across all the callback calls anyway. We cannot
*quite* remove the current_issuer field because it is used as a
communication channel between get_crl and check_crl callbacks, and we
can't change the function signatures without first fixing some broken
code in gRPC.
Update-Note: Removed an unused function.
Change-Id: I545e654d6c8f0a7973636217f3da27d05c0ef831
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65068
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This seems to only be reachable via the verify callback, but it is
possible for internal_verify to see a single-element certificate that
isn't self-signed. There's a special error code for this. We probably
can safely change it, but cover the codepath in the meantime.
Change-Id: Id4c81e1826f0b43b369e8f00de36313e5fa4360d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65053
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Per the bug, we were waiting for the launch to stick. It has now stuck,
so finish the job.
Also fix the rebase-errors.py scripts. They stopped working after the
migration.
Update-Note: SHA-1 certificates with the Netscape SGC OID will no longer
skip their EKU check in the new verifier. By default, SHA-1
certificates are rejected, in which case this only impacts error
reporting, not which certificates are ultimately accepted.
Fixed: chromium:843735
Change-Id: I44df6a0ee80625c50e0bdf03fb775df9913fd141
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65054
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
No change to tests, but makes it easier to test X509_STORE_CTX-level
features.
Change-Id: I26a02ce51b4970aedce06f64d4ebef0dba154597
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65052
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Also X509_REQ_check_private_key didn't handle unknown key type case.
Clean those up and align with X509_check_private_key.
Change-Id: I7b16f85662943e4b226221a01e1092cf62afc643
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65051
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Whenever the object is mutated, we can simply refresh the cached
EVP_PKEY. This aligns with OpenSSL, which computes it eagerly these
days. This removes the need to lock things, and also makes it easy to
implement the get0 versions of the functions from OpenSSL.
Change-Id: Ib17b654af694817edc43e4742d9baf9ed05c676e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65050
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Previously, if we just skipped signature checks, zero tests would fail.
This is perhaps not ideal.
Change-Id: Ife42f32d06c01b48afa9da26a8bd25814f9a909f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65049
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Adam Langley
David Benjamin
Adam Langley
Brian Smith
Sean McGrail
Bob Beck
Tom Hughes