| commit | dd81bf770793e16352072cf397be030f0fd540e0 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Oct 18 21:41:30 2022 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Nov 14 18:10:26 2022 +0000 |
| tree | 819604b2c4ee4581a72469bf195b0680fbd299ee | |
| parent | 41eb357d05e1603a15b23c4c7f21b5240664453a [diff] |
Introduce ossl_ssize_t and use it in ASN1_STRING_set. We have a number of APIs that cannot migrate to size_t because OpenSSL used negative numbers as some special indicator. This makes it hard to become size_t-clean. However, in reality, the largest buffer size is SSIZE_MAX, or, more accurately PTRDIFF_MAX. But every platform I've ever seen make ptrdiff_t and size_t the same size. malloc is just obligated to fail allocations that don't fit in ssize_t. ssize_t itself is not portable (Windows doesn't have it), but we can define ossl_ssize_t to be ptrdiff_t. OpenSSL also has an ossl_ssize_t (though they don't use it much), so we're also improving compatibility. Start this out with ASN1_STRING_set. It still internally refuses to construct a string bigger than INT_MAX; the struct can't hold this and even if we fix the struct, no other code, inside or outside the library, can tolerate it. But now code which passes in a size_t (including our own) can do so without overflow. Bug: 428, 516 Change-Id: I17aa6971733f34dfda7d971882d0f062e92340e9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54953 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@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: