| commit | 114fa727b7281bf532d037036356359619c730be | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Dec 30 13:37:30 2022 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Jan 18 03:24:46 2023 +0000 |
| tree | 46c54c0971d089a5e29ad84ffef74f06b9e56dc7 | |
| parent | 65ad925f51d879f8babd22ecb2ca4dc779b2cc24 [diff] |
Reduce caller requirements on X509V3_CTX. This relaxes two caller requirements: First, although one needs to initialize X509V3_CTX in two parts, some callers forget to this. This works some of the time on accident, because most codepaths read ctx->db. But if one were to read it, it'd be uninitialized. Since all the entrypoints take a CONF anyway, and always match them, just implicitly initialize the CONF half of the X509V3_CTX with the provided one. Second, allow X509V3_CTX to be NULL. Some codepaths in the library check for NULL (or don't use it) and some do not. Enough codepaths don't check that it really cannot be considered to work, but enough do that a caller could mistakenly pass in NULL and have it mostly work. I've seen one caller mistakenly do this. Since we have to copy the X509V3_CTX for the first relaxation anyway, allow it to be NULL and fill in an empty one when omitted. Update-Note: If using different CONFs in the X509V3_CTX and the function parameter, the function parameter is now always used. No callers do this, and it's somewhat arbitrary which is used. (The generic code always uses the one in ctx. The @section syntax uses the parameter. Then the per-extension callbacks use the ctx.) Change-Id: I9fc15a581ea375ea06c4b082dcf0d6360be8144f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56109 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@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: