| commit | bfdd1a93084f55d01448648e98a3fb3e97e0e8c1 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Jun 29 16:26:38 2018 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Jul 03 22:57:56 2018 +0000 |
| tree | cd0d3f7444c46919baf569f074f9a88186d3efd4 | |
| parent | 58150ed59b69c2e6c35379d96f4f43c5f5838d03 [diff] |
Give SSL_SESSION a destructor. Previously we'd partially attempted the ssl_st / bssl::SSLConnection subclassing split, but that gets messy when we actually try to add a destructor, because CRYPTO_EX_DATA's cleanup function needs an ssl_st*, not a bssl::SSLConnection*. Downcasting is technically undefined at this point and will likely offend some CFI-like check. Moreover, it appears that even with today's subclassing split, New<SSL>() emits symbols like: W ssl_st*& std::forward<ssl_st*&>(std::remove_reference<ssl_st*&>::type&) The compiler does not bother emitting them in optimized builds, but it does suggest we can't really avoid claiming the ssl_st type name at the symbol level, short of doing reinterpret_casts at all API boundaries. And, of course, we've already long claimed it at the #include level. So I've just left this defining directly on ssl_session_st. The cost is we need to write some silly "bssl::" prefixes in the headers, but so it goes. In the likely event we change our minds again, we can always revise this. Change-Id: Ieb429e8eaabe7c2961ef7f8d9234fb71f19a5e2a Reviewed-on: https://boringssl-review.googlesource.com/29587 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 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.
There are other files in this directory which might be helpful: