| commit | 2a52444f9d9e66b0dc317b8b25bdb4a3e4c7518c | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu Mar 16 01:01:27 2023 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Mar 21 22:18:39 2023 +0000 |
| tree | 4c388c5780ccfd5ec17a65f7910603b738287305 | |
| parent | 172b291d3db3fa17b51e76cf02eb2d5e24db1af0 [diff] |
Reimplement X509 parsing without templates This is a cursory conversion and is, currently, very tedious because it needs to bridge calling conventions. After tasn_*.c and all the underlying primitives have CBS/CBB-based calling conventions, this should be a lot cleaner. This is to break a dependency cycle: - We'd like to rewrite d2i_X509 with CBS - To do that, we need to rewrite its underlying types with CBS - Those parsers are tied up in tasn_dec.c, so we effectively need to rewrite tasn_dec.c with CBS. - CBS is designed for DER, not BER, so such a change would most naturally switch the TLV parser to require DER. - We've *almost* done that already except https://boringssl-review.googlesource.com/c/boringssl/+/51626 had to stop at non-minimal definite lengths, which are allowed in BER but forbidden in DER. See b/18228011 for a bunch of certificates which have a non-minimal definite length at *just* the signature field. - So, to do that, we'd ideally special case just that field, or BIT STRINGs in general, to tolerate minimal lengths. That's easiest done when d2i_X509 is CBS, so we can just do what we want in imperative code. And thus we're back full circle. So, detach X509 from the templates now. It's a bit tedious because we need to switch calling conventions for now, but it breaks the cycle. Later, we can revisit this and get all the benefits of a fully CBS-based path. For now, I haven't added an ASN1_ITEM. If it comes up, we can make an EXTERN ASN1_ITEM. Update-Note: The ASN1_ITEM removal means custom ASN.1 templates (which are discouraged in favor of our much simpler CBS and CBB types) using X509 will fail to compile. We don't believe anyone is relying on this, but this can be restored if we find something. Update-Note: Certificate parsing is slightly stricter: the outermost TLVs, except for the signature field, no longer accept non-minimal lengths, as mandated by DER. This strictness was broadly already applied by the libssl parser. Bug: 547 Change-Id: Ie5ad8ba4bb39f54fdd3dd45c53965b72a3850709 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58185 Reviewed-by: Bob Beck <bbe@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: