commit | 2f87112b963fe9dee6a75b23a8dae45000001063 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Fri May 20 14:27:17 2016 -0400 |
committer | Adam Langley <agl@google.com> | Mon May 23 18:15:03 2016 +0000 |
tree | acd4587d5c860842ec3619a325db59465ae105b5 | |
parent | 7e7a82d962d84b5dea95bb5dfe82616b3551e3bc [diff] |
Never expose ssl->bbio in the public API. OpenSSL's bbio logic is kind of crazy. It would be good to eventually do the buffering in a better way (notably, bbio is fragile, if not outright broken, for DTLS). In the meantime, this fixes a number of bugs where the existence of bbio was leaked in the public API and broke things. - SSL_get_wbio returned the bbio during the handshake. It must always return the BIO the consumer configured. In doing so, internal accesses of SSL_get_wbio should be switched to ssl->wbio since those want to see bbio. For consistency, do the same with rbio. - The logic in SSL_set_rfd, etc. (which I doubt is quite right since SSL_set_bio's lifetime is unclear) would get confused once wbio got wrapped. Those want to compare to SSL_get_wbio. - If SSL_set_bio was called mid-handshake, bbio would get disconnected and lose state. It forgets to reattach the bbio afterwards. Unfortunately, Conscrypt does this a lot. It just never ended up calling it at a point where the bbio would cause problems. - Make more explicit the invariant that any bbio's which exist are always attached. Simplify a few things as part of that. Change-Id: Ia02d6bdfb9aeb1e3021a8f82dcbd0629f5c7fb8d Reviewed-on: https://boringssl-review.googlesource.com/8023 Reviewed-by: Kenny Root <kroot@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.
There are other files in this directory which might be helpful: