| commit | 117f86ef7152be47bd223ac602211a6beb2b1ab9 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Aug 29 15:16:25 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Sep 03 22:02:42 2025 -0700 |
| tree | 1082eb8907e5988aec6c69970e1dd9349bd76269 | |
| parent | a317d59c79cf4f72d30f24ba2eaeb0a7523caf4a [diff] |
Rewrite X509's parser with CBS/CBB In doing so, embed a whole host of types into X509. With all this, we can *finally* add extra parameters to the parser, like lists of supported algorithms or flag-protecting future changes. In the previous state, it went through a very messy reflection-based framework. Since we now control the parser entrypoint, this also means we can handle the cached encoding differently. Just to make the X509_parse_from_buffer and d2i_X509 flows more uniform, we now always save a CRYPTO_BUFFER containing the whole certificate, and then TBSCertificate marshalling finds the TBSCertificate from there. (Though it is still possible to create X509 objects without CRYPTO_BUFFERs.) That in turn means the generic ASN1_ENCODING path doesn't need to store a CRYPTO_BUFFER anymore, so all that is now unwound. If we rewrite the CSR and CRL parsers, then ASN1_ENCODING can be removed entirely. As a bonus, this new parser is significantly faster! Before: Did 1037634 Parse X.509 certificate operations in 5000690us (207498.2 ops/sec) After: Did 1318068 Parse X.509 certificate operations in 5000462us (263589.2 ops/sec) (The X509_NAME parser is still using tasn_dec, so there's still some overhead there. This also does not remove the overhead from X509's in-memory representation where lots of parts of the certificate get copied separate allocations.) Update-Note: This CL is not expected to change the external behavior of the X.509 parser, but it's a lot of code that had to get shuffled around, so if something funny happens around X.509, this is a likely culprit. Bug: 42290417 Change-Id: Ia4142f5e8d31b041176a545379c7df30e946a670 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81781 Reviewed-by: Adam Langley <agl@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:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: