| commit | 8fe61c3d560df9f3e2f67aada7c96046f94f6329 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sat Aug 30 16:02:08 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Sep 15 16:49:04 2025 -0700 |
| tree | 8d79e18ffde2be2b6db41705a9a2cf4b6d063e7a | |
| parent | 336efd412e4533ab3461e0cd9cc193c964f59388 [diff] |
Rewrite the X509_NAME parser The old parser was a mess. It has to deal with X509_NAME using a slightly different in-memory represtation than tasn_dec expects, and it has to populate cached fields. On top of that, the handling of the cache was not thread-safe. It previously worked by first using the tasn_dec machinery to parse a STACK_OF(STACK_OF(X509_NAME_ENTRY)), and then flattening it. Then it makes a *new* STACK_OF(STACK_OF(X509_NAME_ENTRY)) with canonicalized fields. Then it re-encodes that with tasn_enc to save the canonicalized form. Instead of all that, parse with CBS so we don't need an allocated intermediate representation. We can just write it out into the X509_NAME representation as we parse it. For the two cached fields, fix the thread-safety issue by wrapping it in a struct and managing it with an atomic pointer. I had vaguely hoped we could avoid this, but that seems too complicated with the API we've got. When computing the cached encodings, rather than making a new allocated intermediate representation, we can just write a canonicalized encoder and write it straight into a single CBB, so we only have one growable array's worth of buffer. It's faster too! Before: Did 1319499 Parse X.509 certificate operations in 5001015us (263846.2 ops/sec) After: Did 1794529 Parse X.509 certificate operations in 5000632us (358860.4 ops/sec) Subsequent CLs will make the API const-correct, test threading, and embed the X509_NAMEs into the X509 struct. One nuisance: it's hard for an infallible x509_name_init to initialize a STACK_OF(X509_NAME_ENTRY). For now I just made the zero state legal and the add function materializes the STACK_OF on demand. We don't expose the underlying object, so it doesn't matter much. Really we should stop believing in fallible mallocs. Bug: 42290417, 42290269 Change-Id: I0081c75dc06c76c3863eb9418e61262953c9179f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81891 Auto-Submit: David Benjamin <davidben@google.com> 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:
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: