tree 496b6962b26762e10406ee1fdd5ed0d60be259a4
parent f33224eb499a8f96aff9c15b71f99ec664818278
author David Benjamin <davidben@google.com> 1756320413 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1756957649 -0700

Avoid one malloc indirection in X509

This is very minor in itself but the aim is to start setting up the
patterns to rewrite the X509_CINF parser with CBS/CBB. In doing so, I'd
like to directly embed some of the many child fields in X509. It saves
some tiny mallocs and avoids worrying about whether the field is null.
To support that, I've made the low-level parsing functions for
crypto/asn1 look like "parse into" rather "parse and return new".

The embed + parse-into pattern also avoids a thorny discrepancy between
d2i_FOO and FOO_new: FOO_new currently fills in every required field,
which is nice because it means, e.g., an X509 actually never has a null
issuer. But if the parser first internally calls X509_new to construct
the X509 and then fills it in, the inner X509_NAME parser will then have
to throw it away and make a new one. As a result, we have this weird
internal x509_new_null function. (tasn_dec.cc avoids this because
internally it actually is a parse-into pattern, not a parse-new pattern.
And then it just keeps allocating objects and checking for errors
everywhere.)

On the flip side, it means a bunch of types have to become embeddable
within the library, instead of always allocated. That means adding
internal init/cleanup functions. All this would be made a lot easier
with C++ constructors and destructors, but there's a lot to work through
there (I'm not thrilled about how we stomp ::~ssl_ctx_st() in libssl.)
So, for now, I'm doing all this C-style.

The immediate reason for revisiting that parser now is to thread
EVP_PKEY_ALG parameters into the SPKI parser. The table-based parser is
makes it very hard to add a new parameter. But I've also wanted to do
this for some time anyway.

Bug: 42290417
Change-Id: I628803992d5091333b9213db18736db2b9911cb0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81771
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>