| commit | b095f0f0ca4ef08de8c5b48045e20206d55173bf | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu May 05 21:50:24 2016 -0400 |
| committer | Adam Langley <agl@google.com> | Fri May 06 17:39:48 2016 +0000 |
| tree | 2b2a23f8d1bac10eb82788448a08c82c599b337e | |
| parent | 2730955e7449989bb982092d3301f89340dbc189 [diff] |
Remove the push argument to ssl_init_wbio_buffer. Having bbio be tri-state (not allocated, allocated but not active, and allocated and active) is confusing. The extra state is only used in the client handshake, where ClientHello is special-cased to not go through the buffer while everything else is. This dates to OpenSSL's initial commit and doesn't seem to do much. I do not believe it can affect renego as the buffer only affects writes; although OpenSSL accepted interleave on read (though this logic predates it slightly), it never sent application data while it believed a handshake was active. The handshake would always be driven to completion first. My guess is this was to save a copy since the ClientHello is a one-message flight so it wouldn't need to be buffered? This is probably not worth the extra variation in the state. (Especially with the DTLS state machine going through ClientHello twice and pushing the BIO in between the two. Though I suspect that was a mistake in itself. If the optimization guess is correct, there was no need to do that.) Change-Id: I6726f866e16ee7213cab0c3e6abb133981444d47 Reviewed-on: https://boringssl-review.googlesource.com/7873 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: