| commit | fcec391b0e90fadbf20f96de56b595925ceb7dd1 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Apr 20 14:58:30 2021 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Apr 22 15:28:32 2021 +0000 |
| tree | cf7f41dd53ad80824833943a0ca0df77524f0358 | |
| parent | ab7811ee8751ea699b22095caa70246f641ed3a2 [diff] |
Remove some BoringSSL-only X509_CINF functions. These functions are not in any released version of OpenSSL. The history is they were added to 1.0.2 beta for CT, but then removed in favor of i2d_re_X509_tbs. We forked in between the two events. I'm not sure what the reasoning was upstream's end. I'm thinking: - X509 currently only captures the serialized TBSCertificate. It might be nice to capture the whole Certificate to avoid needing a serialization in X509_cmp and make it easier to interop with other stacks. (Unclear.) That would require not exporting the X509_CINF standalone for serialization. - The modified bit means, without locking, i2d_X509 is not const or thread-safe. We *might* be able to shift the re-encoding to i2d_re_X509_tbs, which is already inherently non-const. That requires not having X509_CINF_set_modified. I'm not sure how feasible either of these are, but between that, upstream alignment, and X509_CINF otherwise being absent from public accessors, it seems worth removing. Update-Note: X509_get_cert_info, X509_CINF_set_modified, and X509_CINF_get_signature are removed. I believe all callers have been updated. Callers should use i2d_re_X509_tbs, i2d_X509_tbs, and X509_get0_tbs_sigalg instead. Change-Id: Ic1906ba383faa7903973cb498402518985dd838c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46985 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@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: