Update-Note: <openssl/kyber.h> has moved to
<openssl/experimental/kyber.h>
Change-Id: I51d37aeb2b6cfbbaae494cc38f1b0a82669d2692
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66467
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
It is not actually possible to configure an inconsistent certificate and
private key pair (short of mutating the objects after you've configured
them). The functions that configure certificates and private keys will
refuse to get CERT into an inconsistent state.
SSL_CTX_check_private_key is really just checking that you have a
certificate and private key at all. Some callers (notably pyOpenSSL's
tests) are written as if SSL_CTX_check_private_key does something more,
but that's only because they also configure certificate and private key
in the wrong order. If you configure the key first, configuring the
certificate silently drops the mismatched private key because OpenSSL
thinks you're overwriting an identity. SSL_CTX_check_private_key is
really just detecting this case.
Add tests for all this behavior, document that certificates should be
configured first, and then deprecate SSL_CTX_check_private_key because,
in the correct order, this function is superfluous.
This will get shuffled around with SSL_CREDENTIAL, so add some tests
first.
Bug: 249
Change-Id: I3fcc0f51add1826d581583b43ff003c0dea979dd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66447
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Different BY_DIR_ENTRYs don't need to share a lock. Also switch some
code to use OPENSSL_strndup.
Change-Id: I3809e001afb9577bb96aab214e80e173900356fe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66012
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If the file doesn't exist, we'll fail when we go to read it anyway. The
stat call just adds a needless ifdef here.
Change-Id: I00a52f988bc1d45622e559b496ef2293b3719863
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66011
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This (internal) abstraction was originally made for trivial types, but
if we ever got a complex type, we should use C++ copies, not C copies,
to preserve all the rules of that type.
A good STL will specialize std::copy to memmove/memcpy when possible, so
this should not appreciably change the generated code.
Change-Id: I76af334ef667e545dbbbe87315ce5b30a327358c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66427
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
BIO_*_filename, in upstream OpenSSL, opens in binary mode on Windows,
not text mode. We seem to have lost those ifdefs in the fork. But since
C mandates the 'b' suffix (POSIX just ignores it), apply it consistently
to all OSes for simplicity.
This fixes X509_FILETYPE_ASN1 in X509_STORE's file-based machinery on
Windows.
Also fix the various BIO_new_file calls to all specify binary mode.
Looking through them, I don't think any of them care (they're all
parsing PEM), but let's just apply it across the board so we don't have
to think about this.
Update-Note: BIO_read_filename, etc., now open in binary mode on
Windows. This matches OpenSSL behavior.
Change-Id: I7e555085d5c66ad2f205b476d0317570075bbadb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66009
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Writing these tests revealed that actually this has been broken on
Windows this whole time!
First, the APIs to configure a directory actually configure a
colon-separated list of directories. But file paths contain colons on
Windows, so the actual separator on Windows is semicolon. But that got
lost in the fork at some point. This CL fixes that.
Second, X509_FILETYPE_ASN1 is broken because of a text vs binary mode
mixup. The following CL will fix this.
Some of the behaviors tested here around CRLs are not quite reasonable.
See https://crbug.com/boringssl/690 for details. For now, I've tried to
capture the existing behavior. As BY_DIR actually maintains some shared
mutable state, I've also added TSAn tests.
Another subtlety is that multiple CAs with the same name work, but the
reason they work is pretty messy because OpenSSL's internal interfaces
are incompatible with it. Instead, OpenSSL works around itself with the
X509_STORE cache. These tests do not cover this case, but a subsequent
CL will add tests for it.
Change-Id: Ifd8f2faea164edb0eda771350cd9bf6dc94104e7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66008
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Avoid rewriting the FILE scoper, and deal with the Android problem in
one place. This header will also, in the next CL, be the home for a
temporary directory helper for hash_dir.
Change-Id: I4be69ef6c2ac3443b80ee8852bcce4078bf7f118
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66007
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Now that delegated credentials comes with its own sigalg list (hooray
for wasted ClientHello bytes), we don't need a
delegated_credential_requested. It's already implicit in whether we
parsed any sigalgs.
Change-Id: I5169e4b24a41dd4973fc581087c881d34b5075fa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66373
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
No one would ever do this, but it works today and we should keep it
working. As part of certificate selection, we'll be introducing an
SSL_CREDENTIAL object. In doing so, the existing APIs will mutate a
built-in "default" credential. If we made a shallow copy, it would break
things.
Bug: 249
Change-Id: I75b1486289659611184a42e87771a6cf7ddb5aa7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66372
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
The CERT structure is never null.
Change-Id: I92436e1ad6156a9f79d30f4f5e989022e8fd0e9d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66371
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If we move SSL_certs_clear to ssl_cert.cc, ssl_cert_clear_certs does not
need to be in the header. Moreover, its only other caller, ~CERT(), does
not need to call it. Now that everything outside of SSL_X509_METHOD is
managed with scopers, the destructor does it automatically. And
cert_free on SSL_X509_METHOD already automatically calls cert_clear, so
it's a no-op to do it again.
Change-Id: Ief9c704cc45440288783564ac4db4a27fbec1bfc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66370
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This is still a bit more tedious than I'd like, but we've got three of
these and I'm about to add a fourth. Add something like Chromium's base
class. But where Chromium integrates the base class directly with
scoped_refptr (giving a place for a static_assert that you did the
subclassing right), we don't quite have that since we need to integrate
with the external C API.
Instead, use the "passkey" pattern and have RefCounted<T>'s protected
constructor take a struct that only T can construct. The passkey ensures
that only T can construct RefCounted<T>, and the protectedness ensures
that T subclassed RefCounted<T>. (I think the latter already comes from
the static_cast in DecRef, but may as well.)
Change-Id: Icf4cbc7d4168010ee46dfa3a7b0a2e7c20aaf383
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66369
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also rename to pass and pass_len, which makes a bit more sense for what
these are.
Change-Id: If3421ed7890c92cd11130641a8a2e090cc7f8b91
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65810
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Also remove some of the comments that, with the constants, don't provide
any real value.
Change-Id: Ie73d840ac5613a6750796e21a9ab1d644edfe5b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66448
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This took a little restructuring because they were previously all one
big function. Some notes:
- label() and set_label() in x86 perlasm default to function-scoped. But
static_label() marks a label as file-scoped, which is why "pic_point"
and "K256" work.
- There's a pretty sizeable common preamble. I just copied it to each
for simplicity. I'm pretty sure some of it is wasted, but it's
definitely not all wasted, between loading parameters, setting up
stack alignment, and saving the old stack location. But I'm not sure
if all those 16 bytes are actually used.
Bug: 673
Change-Id: I6e8671d05d07cb4676ecf117dd56e2ed355c5d19
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65874
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
In TLS 1.2, cipher suite negotiation is tied up with a ton of other
decisions. Even though both sides have an ECDHE_RSA cipher in common, it
may not work because there isn't a common ECDHE curve or sigalg. In that
case, ideally we would consider a non-ECDHE_RSA cipher suite, notably
one of the legacy RSA key exchange ciphers.
If there is no ECDHE curve common, we already did this. However, if
there was no sigalg in common, we would fail the connection rather than
consider RSA key exchange.
Giving this case a lifetime would normally be unimportant as RSA key
exchange is thoroughly deprecated, but the SSL_CREDENTIAL work will need
to consider signature algorithm matches, at which point we'll pick up
behavior like this anyway. So I'm implementing it separately here just
to get the behavior change out of the way.
Update-Note: TLS 1.2 servers will now consider RSA key exchange when the
signature algorithm portion of ECDHE_RSA fails. Previously, the
connection would just fail. This change will not impact any connections
that previously succeeded, only make some previously failing connections
start to succeed. It also changes the error returned in some cases from
NO_COMMON_SIGNATURE_ALGORITHMS to NO_SHARED_CIPHER.
Bug: 249
Change-Id: I4a70036756ea998f38ea155f208e8122bf9a5b44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66368
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Historically, OPENSSL_ia32cap_P used reserved bit 20 to trigger some
variation in the RC4 implementation. That same bit was used in
upstream's f889bb03841c69330d1e14a873c9982d3702f2d0 to disable some
optimization on the Pentium 4.
We've long since always cleared that flag (see cpu_intel.c), so this is
dead code. Remove it.
Change-Id: Ib9c0d88235617941833eb8aabb17a4713bdf6606
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65873
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
These three aren't part of some larger category of functions.
Bug: 426
Change-Id: I94c977b20c6e6beb51df9d89f86851c960b4dfc6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65809
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
sha256-586.pl and sha512-586.pl have their own unique challenges, so
I'll do them separately.
Bug: 673
Change-Id: Ic9be0454fddf75e7f49bcccd8a86a4ff8862ff67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65872
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We always pass this, so checks are redundant. Note this doesn't control
the SSE2 runtime checks, just whether SSE2 code is emitted.
Change-Id: I159806928643915afecf738dcac218007ba94600
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65869
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Although the comments say draft-03, we're currently on draft-06.
dcd6e447eb forgot to update all the
comments.
The final RFC is identical to draft-06, except
expected_cert_verify_algorithm was renamed to dc_cert_verify_algorithm,
so this is just changing comment and renaming something.
While I'm here, write the codepoint in decimal instead of hex, to match
the document and how the other IANA codepoints are written out.
Change-Id: I6d1f362a21eecafeef5bba5879f4158e31c8def4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66367
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
It's possible that
https://boringssl-review.googlesource.com/c/boringssl/+/66268 wouldn't
be needed if we split these back up.
Update-Note: Downstream Bazel and GN builds that build libpki may need
to also list the pki_headers variable.
Change-Id: I61bfc231a9a8019f81b1ad4f7d43a6c4478b7283
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66407
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Upstream OpenSSL will, by default, register an atexit callback to free
globals, even though the process is going to be destroyed anyway.
Not only is this pointless, but it introduces UAFs on race condition if
some thread outlives the main thread. Some projects have started to
notice this, and use OPENSSL_INIT_NO_ATEXIT from 1.1.1b. Add the
constant for compatibility.
We already do not call atexit, so the option is a no-op.
Change-Id: Ia17c529c27646507100ebb69c884e2db9cb70431
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66347
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The latest Rust toolchain has started flagging these (correctly) as
unused.
Change-Id: I702e0ac7bfe47c7546e44debf7f53c4ade8e5dd6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66328
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: Adam Langley <agl@google.com>
There are still a pile of functions left to document, but we're far
enough now that the doc generation is happy to run on this header. Go
ahead and start generating output.
Bug: 426
Change-Id: I4c807d625df3a4a881936e99b5a3fc6559cda6c9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65793
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Probably we could remove this altogether. The new verifier doesn't
support nameRelativeToCRLIssuer.
Change-Id: Ibb2210d513827577656d816fad90f658c2875601
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65792
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I believe the original blocker, gRPC, is now cleared. While I'm here,
make check_imported_libraries print all errors, rather than the first
one. (Though if this sticks, we can probably remove this script. It was
only needed for the C++ runtime check.)
Update-Note: libssl now requires a C++ runtime, in addition to the
pre-existing C++ requirement. Contact the BoringSSL team if this
causes an issue. Some projects may need to switch the final link to
use a C++ linker rather than a C linker.
Change-Id: I94808bf1dad6695ef334e262f3d2426caab0520e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66288
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's less bad than I originally wrote because trust properties only
matter if configured on the X509_STORE. Add a test for this.
This is good because lots of functions trigger d2i_X509_AUX, so I think
we have to assume attackers can specify these values. Nonetheless, this
is surprising, so document which functions trigger this.
Change-Id: I73ce44acfa2a373ef3f3ef09c3e46cea98124f33
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65791
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is a very thin wrapper over CBS_ASN1_* constants, dating from when
the library wanted to avoid as strongly depending on BoringSSL. That's
long stopped being the case, so we may as well just use the underlying
constants. A tad less C++-y, but I don't think the wrapper is buying us
much.
Update-Note: pki/tag.h no longer exists. Use CBS_ASN1_TAG instead of
bssl::der::Tag and CBS_ASN1_* instead of bssl::der::k*.
Change-Id: I09f3f65b406d1a8fe60bfbe1a56d3e485ae84d97
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66067
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Due to https://github.com/rust-lang/rust-bindgen/issues/923, bindgen
does not evaluate constants correctly. This means arithemetic is done
with the wrong type, and more importantly the output has the wrong type.
Ultimately, this is a bug in bindgen, but as that's remains unfixed,
we'll have to work around it.
rust-openssl's bindgen mode works around this by using the build.rs
bindgen driver and registering a callback to fix the type. This won't
work for some of our consumers, which require a hermetic and
reproducible builds. Instead, apply bssl-sys's workaround at the lib.rs
level. This removes a divergence between bssl-sys and rust-openssl's
bindgen mode.
Fixing these types does not mean we recommending using all of these
constants! Many of the options here are ill-defined or produce even more
ambiguous output than most. XN_FLAG_COMPAT is especially fun because it
change the calling convention! The only option anyone should use is
XN_FLAG_RFC2253, as that's at least a well-defined output.
Fixed: 636
Change-Id: Id34b4a46e0cfd6dcb275477d9bb915bda66c787d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66228
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Things like Swift, which attempt to precompile all our headers in C
mode, cannot cope without this.
Change-Id: If59229f5e7cb617da370b65bb39a4af1fbe3f70e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66268
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This removes the need to hand-write rust_wrapper.c, because bindgen can
generate it for us. bindgen 0.65 or later is needed. Earlier versions of
this were buggy.
I've also removed the claim that bssl-sys is somehow a solution for
version skew. That was the original thinking from Android, but it hasn't
worked out. The version skew solution is simply "use bindgen, don't
handwrite bindings".
Android are quite behind their originaly July timeline for adding the
build half of this mechanism, but as this is now in the way of other
work, we're going to proceed with using this now. There is now a
unsupported_inline_wrappers cfg that Android can set to use the old
mechanism.
Update-Note: Rust support now requires your build correctly handle
--wrap-static-fns. On Android, you will need to enable the
unsupported_inline_wrappers cfg option until b/290347127 is fixed.
Chromium doesn't actually use any of the inline functions yet, so we can
handle --wrap-static-fns asynchronously, but I have a CL ready to enable
that.
Fixed: 596
Change-Id: I51fd1108a8c17a06f1bdd9171ebf352cea871723
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58985
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
These were mostly already documented, but fit the current style. Add a
couple tests for some interesting cases.
With this, all we have left to document are:
- Built-in and custom extensions
- Filesystem-based X509_STORE bits
- The APIs to query X509_STORE (mildly annoying because the
sort-of-a-cache-sort-of-not thing is exposed)
Bug: 426
Change-Id: I68c16071b8781f560e6601fd65a7fba9b6efe862
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65790
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
OpenSSL's API uses this weird "index" intermediate integer
representation, which is the same as the ID but offset bit. Just use the
IDs throughout. Also document and deprecate the string-based APIs that
rust-openssl uses.
As a bonus, we remove some int/size_t casts.
Change-Id: I3ffd2ab59bf3c9d96014a028b667b0bd3288b16b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65789
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
X509_PURPOSE can't be fully trimmed because rust-openssl uses a few APIs
to look up purposes by string.
Change-Id: I39e3cec4d8b01ecf7dec1f368fabea4a82eff8e9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65788
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This is only used internally, for X509_PURPOSE_ANY to mark that it has
no corresponding trust value. Countrary to the name, this doesn't mean
to use the default X509_TRUST behavior, but to make it impossible to
configure via X509_STORE_CTX_set_purpose.
Since it's only used in one place, as any value that fails lookup, I've
just put a local define in v3_purp.c.
Change-Id: Id3e44c08528a303132ef09d0a94521af67cc2230
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65212
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This will be needed for https://github.com/python/cpython/pull/114573.
Along the way, document the various functions that expose "query from
X509_STORE". Most of them unfortunately leak the weird caching thing
that hash_dir does, as well as OpenSSL's generally poor handling of
issuers with the same name and CRL lookup, but I don't think it's really
worth trying to unexport these APIs.
Change-Id: I18137bdc4cbaa4bd20ff55116a18f350df386e4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65787
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This is not sufficient to get the correct type on these constants,
because bindgen is broken and does not correctly bind constants. But in
preparation for that bug being fixed, we should at least mark the
headers correctly.
Bug: 636
Change-Id: Ib42a2d4f42a84b385dd7bd286564ccfe457923eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66227
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I907932b04547c4cc779ec4e1edbebf2b12162ffa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66247
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-note: This moves signature_verify_cache.h from the pki
directory to <openssl/pki/signature_verify_cache.h>. Nothing
should really have been depending on this but if so it can
be pre-conditioned on OPENSSL_API_VERSION of 30 or more.
Bug: 660
Change-Id: Ia0ab6e9d16da2a86994ce0dfc6a086e43b79c9ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64787
Reviewed-by: David Benjamin <davidben@google.com>
Currently the way this is used by code checking for errors
is to always assume that what it is looking for has actually
been added as an error. If one of them were added as
a warning, it would in theory do the wrong thing.
We can either delete the warnings, or just change ContainsError
to only consider errors to behave like the code is used today.
Change-Id: Id916281203122fffd1ffc323dc979ff4f8b6425b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66187
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Matt Mueller <mattm@google.com>
This is effectively a derivation of certificate.cc from
chromium_certificate_verifier, without absl.
Bug: 660
Change-Id: I628827a00ab80a733582eee5a25e048dd65bf6b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64171
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Bob Beck
David Benjamin
Zequan Wu
Cindy Lin
Adam Langley
Adam Langley