| commit | 90ceeb021579cdec2c1dd663a5f993e7161f5082 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Jan 23 14:25:39 2024 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Jan 23 21:30:05 2024 +0000 |
| tree | 9cb6425cae90bd67b76183112992f5b93de5995d | |
| parent | 37a91dc5d0db90cb763873c987a2da62b8a94aa0 [diff] |
Make der::Input a little closer to Span This adds a bunch of methods from Span, with the end goal of eventually making it into a typedef for Span<const uint8_t>. In doing so, this makes Input implicitly convertible to Span<const uint8_t> and every other span<const uint8_t> type. For the other direction, I've removed the 'explicit' marker on the Input(Span) constructor. I've kept the older spellings around to avoid forcing us to fix it all at once, but after this rolls in to various places, the next things to do would be: 1. Go through downstream code and switch them to using the span-like spellings. Better yet, have them just pass to their own span type. 2. Since Input <-> Span converts implicitly, we can freely start making our APIs take Span instead of Input. Also start cleaning up a bunch of now unnecessary explicit der::Input(foo) calls now that, like span, it's implicit. 3. Decide what to do with the char vs uint8_t disaster. I'm thinking we add free functions to convert between the two. In doing so, I've also switched some easy places to use more span-y APIs. Bug: 661 Change-Id: I731bb110a4fdadd99cb2894e48f016f0b19110ac Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65668 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Reviewed-by: Matt Mueller <mattm@google.com> Commit-Queue: David Benjamin <davidben@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: