| commit | 8cae3d04ed7264ae99024caff4da79e9a796b915 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Nov 12 14:42:35 2023 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Nov 20 21:10:48 2023 +0000 |
| tree | 4ddaea9928e23069a0472881a64c47d32f9eee80 | |
| parent | 580c04109e8a63d08582b3d948cf54849371a73e [diff] |
Remove the now no-op CRL reasons loop Now that we only process CRLs that cover all reasons: 1. A successful get_crl will always set current_reasons to CRLDP_ALL_REASONS. 2. The last_reasons == current_reasons will never happen. 3. The loop always makes exactly one iteration. A footnote on point 1: it is also possible for the caller to override get_crl. In that case, the caller's get_crl was previously responsible for setting current_reasons, but there was no way to do so. In reality, that callback was actually impossible to use correctly. See https://github.com/openssl/openssl/issues/21679 and https://github.com/openssl/openssl/issues/10211. I previously attempted to remove those first, but gRPC did not notice it was unusable and use it anyway. Instead, they're suppressing X509_V_ERR_UNABLE_TO_GET_CRL via the callback, which is probably working around the bug in their get_crl implementation. Later, when we tackle the callback, we'll probably need to unwind the gRPC mess and, in the process, add a X509_STORE_CTX_set_current_reasons for them to call for OpenSSL compatibility. For now, this change has the side effect of removing the need for them to call that. Bug: 601 Change-Id: Icc5c0fb195d9f66991d0e560911f304e82afa5fd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63936 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: