| commit | 1df70cea5daa391e10f5df9057c60fd740b912ab | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Dec 04 23:48:42 2022 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Feb 01 17:44:52 2023 +0000 |
| tree | 4f0209cd30cec3b169d4f477e2067b78b7c27391 | |
| parent | 2c12ebdf3a97a03b8bab7f4cd3b841926227310f [diff] |
Correctly handle optional ASN1_ITEM_TEMPLATE types. I didn't quite handle this case correctly in https://boringssl-review.googlesource.com/c/boringssl/+/49350, which made it impossible to express an OPTIONAL, doubly-tagged type in crypto/asn1. For some background, an ASN1_ITEM is a top-level type, while an ASN1_TEMPLATE is roughly a field in a SEQUENCE or SET. In ASN.1, types cannot be OPTIONAL or DEFAULT, only fields, so something like ASN1_TFLG_OPTIONAL is a flag an ASN1_TEMPLATE. However, there are many other type-level features that are applied as ASN1_TEMPLATE flags. SEQUENCE OF T and SET OF T are represented as an ASN1_TEMPLATE with the ASN1_TFLG_SEQUENCE_OF or ASN1_TFLG_SET_OF flag and an item of T. Tagging is also a feature of ASN1_TEMPLATE. But some top-level ASN.1 types may be SEQUENCE OF T or be tagged. So one of the types of ASN1_ITEM is ASN1_ITEM_TEMPLATE, which is an ASN1_ITEM that wraps an ASN1_TEMPLATE (which, in turn, wraps an ASN1_ITEM...). Such an ASN1_ITEM could then be placed in a SEQUENCE or SET, where it is OPTIONAL. We didn't correctly handle this case and instead lost the optional bit. Fix this and add a test. This is a little interesting because it means asn1_template_ex_i2d may get an optional bit from the caller, or it may get one from the template itself. (But it will never get both. An ASN1_ITEM_TEMPLATE cannot wrap an optional template because types are not optional.) This case doesn't actually come up, given it doesn't work today. But in my pending rewrite of tasn_enc.c, it made more sense to just make it work, so this CL fixes it and adds a test ahead of time. Bug: 548 Change-Id: I0cf8c25386ddff992bafae029a5a60d026f124d0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56185 Commit-Queue: Bob Beck <bbe@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: