See also 174ba8048a7f2f5e1fca31cfb93b1730d9db8300 from upstream. This
differs from the upstream CL in that:
- We don't silently drop trailing NULs.
- As a NUL-terminated C string, the empty string is a non-NULL pointer
to an array containing a zero byte. Use the latter consistently.
Change-Id: I99c6c4c26be5a1771c56c6ab356425f1b85be41d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49006
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These macros aren't consumed by anything anymore.
Change-Id: Id9616fa0962ae0dbf27bc884c6883dcad9755eb2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48229
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is a bit short of a name to take, and no one seems to be using
it. (OpenSSL has renamed it, but not unexported it.)
Change-Id: I0de74d4d4812678ac3b1ec4b1b126a7748fe952b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48129
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This will also pull in POLICY_MAPPINGS by way of STACK_OF(T) handling.
Change-Id: I8ddc9547647f8cae3800047eb58e1c83f6ae1085
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46104
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
See also CVE-2020-1971, f960d81215ebf3f65e03d4d5d857fb9b666d6920, and
aa0ad2011d3e7ad8a611da274ef7d9c7706e289b from upstream OpenSSL.
Unlike upstream's version, this CL opts for a simpler edipartyname_cmp.
GENERAL_NAME_cmp is already unsuitable for ordering, just equality,
which means there's no need to preserve return values from
ASN1_STRING_cmp. Additionally, the ASN.1 structure implies most fields
cannot be NULL.
(The change from other to x400Address is a no-op. They're the same type.
Just x400Address is a little clearer. Historical quirks of the
GENERAL_NAME structure.)
Change-Id: I4b0ffe8e931c8ef916794a486e6a0d6d684c0cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44404
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I77e08b88afa8a1f4e28449bf728eccc2c2f6f372
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43944
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These are a bit of a mess. Callers almost never handle the error
correctly.
Change-Id: I85ea6d4c03cca685f0be579459efb66fea996c9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43804
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is needed to fix all the config APIs to take const char *. I've
split it out as it's the only incompatible half of the change.
Update-Note: External definitions of X509V3_CONF_METHOD will need fix
the types of their functions. There should not be any of these (probably
hide this struct), but if there are, this aligns with upstream OpenSSL.
Change-Id: I6e760cfbca5d3f408215b8f3744acd1fd7f31391
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42727
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Although extensions are accessible via X509_get_ext_d2i, OpenSSL's X509
object carries caches of a number of extensions. OpenSSL added accessors
for some of these in 1.1.0 (X509_get0_subject_key_id) and 1.1.1d (the
others), so mirror this. Note that, although they look like simpler
getters, the error-handling is tricky.
(For now I'm just looking to mirror OpenSSL's accessors and finally make
the structs opaque. Go's x509.Certificate structure also recognizes a
collection of built-in certificate fields, but error-handling is in the
parser. That could be one path out of this cached fields mess, at the
cost of making the parse operation do more work.)
Change-Id: I051512aa296bd103229ba6eb2b5639d79e9eb63f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42624
Reviewed-by: Adam Langley <agl@google.com>
These aren't used within the verifier and no one ever extracts them.
Update-Note: Parsers for these two extensions are removed. Parsing the
types directly or passing NID_sxnet and NID_pkey_usage_period into
X509V3_get_d2i, or *_get_ext_d2i will no longer work.
Change-Id: I359e64466fd0c042eda45c41cbc0843ebb04df9f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Actually making crypto/asn1 and crypto/x509 const-correct will be a tall
order, between all the hidden caches, non-const ASN.1 macros, and
ambiguity between mutable and immutable getters. But upstream
const-corrected a number of things, so align with them. (In particular,
it is not currently possible to usefully use a non-const X509_NAME.)
I think I've gotten most of x509.h. I started going through x509v3.h,
but all the conf bits take non-const char* pointers, which shows up in
the public (but probably unused) X509V3_CONF_METHOD, so I've left it
alone in this CL.
For some reason, OpenSSL made X509_get_subject_name a const-to-non-const
function but kept X509_get_serialNumber uniformly non-const while adding
a uniformly const X509_get0_serialNumber. I've just mirrored this for
compatibility's sake.
Change-Id: Ia33a7576165cf2da5922807fc065f1f114b0f84c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42584
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley