| commit | c2b7df5850398dc7c73146c07f6eed95dd363a48 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sat Nov 18 19:31:24 2023 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Nov 27 16:59:32 2023 +0000 |
| tree | 37d600a8bcd7cf4234a8155018c85fc5f4b063fe | |
| parent | 1685bd140f6eeb6939c73756be70c888dde32c5e [diff] |
Add X509_OBJECT_new and X509_OBJECT_free This is a bit of a mess. The immediate motivation here is that there is no legitimate reason to ever call X509_OBJECT_free_contents outside of the library. Unsurprisingly, this means rust-openssl uses it. rust-openssl uses it because they want to be able to free X509_OBJECTs. Add OpenSSL 1.1.x's X509_OBJECT_free, which is what they should be using it instead. As it turns out, they don't *actually* need to free X509_OBJECTs. This is just some design mistake that cause them to need free functions for types they never free. On top of that, the only reason rust-openssl references X509_OBJECT is for X509_STORE_get0_objects, but their use of that API is a Rust safety violation anyway. It's all a mess. As for whether freeing it ever makes sense, the question is whether X509_STORE_get_by_subject needs to be a public API. In so far as it is public, callers would need to create empty X509_OBJECTs as an output, now that X509_OBJECT is opaque. There are also other users of X509_STORE_get0_objects that might benefit from an X509_STORE_get1_objects, in which case X509_OBJECT_free will be useful. For now just to unblock fixing the more immediate rust-openssl mistake (rather than the underlying mistake), add the APIs that X509_STORE_get_by_subject callers would need if they existed. There's quite a bit to clean up around X509_OBJECT, but start by adding these APIs. As part of this, since rust-openssl prevents us from removing X509_OBJECT_free_contents, deprecate it and fix it to leave the X509_OBJECT in a self-consistent state. (This is moot because rust-openssl will never call it, but still.) Change-Id: I78708f2d2464eb9a18844fef0d62cb0a727b9f47 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64129 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@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: