| commit | b9ee7b143135e6e070e4d6582ac7d8121978f53a | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Aug 09 22:58:03 2021 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Aug 11 21:21:37 2021 +0000 |
| tree | 0b00c6528da1c0305ae8d50682739affce2d9028 | |
| parent | 1b2db8c7c4abba4bd8d820421fc911c1a5317cbe [diff] |
Fix negative ENUMERATED values in multi-strings. I noticed this while I was reading through the encoder. OpenSSL's ASN.1 library is very sloppy when it comes to reusing enums. It has... - Universal tag numbers. These are just tag numbers from ASN.1 - utype. These are used in the ASN1_TYPE type field, as well as the ASN1_ITEM utype fields They are the same as universal tag numbers, except non-universal types map to V_ASN1_OTHER. I believe ASN1_TYPE types and ASN1_ITEM utypes are the same, but I am not positive. - ASN1_STRING types. These are the same as utypes, except V_ASN1_OTHER appears to only be possible when embedded inside ASN1_TYPE, and negative INTEGER and ENUMERATED values get mapped to V_ASN1_NEG_INTEGER and V_ASN1_NEG_ENUMERATED. Additionally, some values like V_ASN1_OBJECT are possible in a utype but not possible in an ASN1_STRING (and will cause lots of problems if ever placed in one). - Sometimes one of these enums is augmented with V_ASN1_UNDEF and/or V_ASN1_APP_CHOOSE for extra behaviors. - Probably others I'm missing. These get mixed up all the time. asn1_ex_i2c's MSTRING path converts from ASN1_STRING type to utype and forgets to normalize V_ASN1_NEG_*. This means that negative INTEGERs and ENUMERATEDs in MSTRINGs do not get encoded right. The negative INTEGER case is unreachable (unless the caller passes the wrong ASN1_STRING to an MSTRING i2d function, but mismatching i2d functions generally does wrong things), but the negative ENUMERATED case is reachable. Fix this and add a test. Change-Id: I762d482e72ebf03fd64bba291e751ab0b51af2a9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48805 Commit-Queue: David Benjamin <davidben@google.com> 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: