| commit | a406ad76ad31c07b094ff60300146724a1448251 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Oct 04 19:21:01 2021 -0400 |
| committer | Adam Langley <agl@google.com> | Tue Oct 05 18:01:36 2021 +0000 |
| tree | f26e7b6dcb8a79171aaa524dd6bfbb3e16434c2a | |
| parent | f5e601275c38b0b2be437e392f654601725f9d66 [diff] |
Make ASN1_NULL an opaque pointer. crypto/asn1 represents an ASN.1 NULL value as a non-null ASN1_NULL* pointer, (ASN1_NULL*)1. It is a non-null pointer because a null pointer represents an omitted OPTIONAL NULL. It is an opaque pointer because there is no sense in allocating anything. This pointer cannot be dereferenced, yet ASN1_NULL is a typedef for int. This is confusing and probably undefined behavior. (N1548, 6.3.2.3, clause 7 requires pointer conversions between two pointer types be correctly aligned, even if the pointer is never dereferenced. Strangely, clause 5 above does not impose the same requirement when converting from integer to pointer, though it mostly punts to the implementation definition.) Of course, all of tasn_*.c is a giant strict aliasing violation anyway, but an opaque struct pointer is a slightly better choice here. (Note that, although ASN1_BOOLEAN is also a typedef for int, that situation is different: the ASN1_BOOLEAN representation is a plain ASN1_BOOLEAN, not ASN1_BOOLEAN*, while the ASN1_NULL representation is a pointer. ASN1_NULL could have had the same treatment and even used a little less memory, but changing that would break the API.) Update-Note: Code that was assuming ASN1_NULL was an int typedef will fail to compile. Given this was never dereferencable, it is hard to imagine anything relying on this. Bug: 438 Change-Id: Ia0c652eed66e76f82a3843af1fc877f06c8d5e8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49805 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.
Project links:
There are other files in this directory which might be helpful: