commit | 6fff386492d9f316f5f780ff9d0ddaf1700f98a9 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Wed Jun 21 21:07:04 2017 -0400 |
committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Jun 22 02:45:37 2017 +0000 |
tree | 5885c6a7cef196c20ebebb175663240580d1ddb5 | |
parent | cd60bf0e0a5a710a90d68a7496ef9540305bfd32 [diff] |
Support standard RFC cipher suite names alongside OpenSSL ones. Both Conscrypt and Netty have a lot of logic to map between the two kinds of names. WebRTC needed an SSL_CIPHER_get_rfc_name for something. Just have both in the library. Also deprecate SSL_CIPHER_get_rfc_name in favor of SSL_CIPHER_standard_name, which matches upstream if built with enable-ssl-trace. And, unlike SSL_CIPHER_get_rfc_name, this does not require dealing with the malloc. (Strangely this decreases bssl's binary size, even though we're carrying more strings around. It seems the old SSL_CIPHER_get_rfc_name was somewhat large in comparison. Regardless, a consumer that disliked 30 short strings probably also disliked the OpenSSL names. That would be better solved by opaquifying SSL_CIPHER and adding a less stringy API for configuring cipher lists. That's something we can explore later if needed.) I also made the command-line tool print out the standard names since they're more standard. May as well push folks towards those going forward. Change-Id: Ieeb3d63e67ef4da87458e68d130166a4c1090596 Reviewed-on: https://boringssl-review.googlesource.com/17324 Reviewed-by: Robert Sloan <varomodt@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
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: