commit | d0f14f3981943eb60687bc46f95546a3e1c72b9e | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Tue Mar 08 15:55:42 2022 -0500 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Mar 18 19:17:52 2022 +0000 |
tree | 981a2593235b12fd7bf2f0c78b5fce356f30ef91 | |
parent | c7a3c46574e7fc32357b2cc68f961c56c72b0ca4 [diff] |
Document and tidy up X509_alias_get0, etc. The getters would leave the length uninitialized when empty, which is dangerous if the caller does not check. Instead, always fill it in. This opens a can of worms around whether empty alias and missing alias are meaningfully different. Treating {NULL, 0} differently from {non-NULL, 0} has typically caused problems. At the PKCS#12 level, neither friendlyName, nor localKeyId are allowed to be empty, which suggests we should not distinguish. However, X509_CERT_AUX, which is serialized in i2d_X509_AUX, does distinguish the two states. The getters try to, but an empty ASN1_STRING can have NULL data pointer. (Although, when parsed, they usually do not because OpenSSL helpfully NUL-terminates it for you.) For now, I've just written the documentation to suggest the empty string is the same as the missing state. I'm thinking we can make the PKCS#12 functions not bother distinguishing the two and see how it goes. I've also gone ahead and grouped them with d2i_X509_AUX, although the rest of the headers has not yet been grouped into sections. Bug: 426, 481 Change-Id: Ic9c21bc2b5ef3b012c2f812b0474f04d5232db06 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51745 Reviewed-by: Adam Langley <agl@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: