Adding the ending macros to StatementMacros tells clang-format the macro
terminates a statement. Adding trailing commas in the middle keeps it
from trying to bundle the curly brace with the next statement.
Also add a few other trailing commas that clang-format otherwise indents
awkwardly.
Change-Id: I0b2ba9cf07bc775649fa1e92de3e5bb2e2b0b20b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52728
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
While C allows function pointer casts, it is UB to call a function with
a different type than its actual type signature. That is, even though
`void f(int *)` and `void g(void *)` have the same ABI, it is UB to
cast `f` to a `void(*)(void *)` and then call it through that pointer.
Clang CFI will try to enforce this rule.
The recent CL to call X509_print in tests revealed that all the i2? and
?2i callbacks in X509V3_EXT_METHODs were implemented with functions of
the wrong type, out of some combination of missing consts and void*
turned into T*.
This CL fixes this. Where the function wasn't exported, or had no
callers, I just fixed the function itself. Where it had extension
callers, I added a wrapper function with a void* type.
I'm not positive whether the wrappers are the right call. On the one
hand, keeping the exported functions as-is is more type-safe and more
OpenSSL-compatible. However, most (but not all) uses of these are in
other code defining X509V3_EXT_METHODs themselves, so the void*
signature is more correct for them too. And the functions have a type
signature meant for X509V3_EXT_METHOD, complete with method pointer.
I've gone with leaving the exported ones as-is for now. Probably the
right answer anyway is to migrate the external callers, of either type
signature.
Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Although the preceding CL fixes x509v3_bytes_to_hex to work with the
empty string, it's not really a good representation for zero. Zero as an
ASN1_INTEGER is sometimes the empty string (default-constructed) and
sometimes a single zero byte (parsed). bytes_to_hex also doesn't capture
the sign bit.
Instead, use X509V3_add_value_int, matching most of the other i2v, etc.,
functions in crypto/x509v3. X509V3_add_value_int calls i2s_ASN1_INTEGER,
which prints small values in decimal and large values in hexadecimal
with a 0x prefix.
It is unclear to me whether i2v and v2i are generally expected to be
inverses. i2v (or i2s or i2r) is used when printing an extension, while
v2i is used when using the stringly-typed config file APIs. However,
i2v_AUTHORITY_KEYID does not consume the "serial" key at all. It
computes the serial from the issuer cert.
Oddly, there is one ASN1_INTEGER,
PROXY_CERT_INFO_EXTENSION.pcPathLengthConstraint, which uses
i2a_ASN1_INTEGER instead. That one uses hexadecimal without the "0x"
prefix, and with newlines. Interestingly, its r2i function is not the
reverse of i2r and parses the s2i_ASN1_INTEGER format.
Between those, I'm assuming they're not necessarily invertible.
Change-Id: I6d813d1a93c5cd94a2bd06b22bcf1b80bc9d937b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51628
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
See upstream commits:
32f3b98d1302d4c0950dc1bf94b50269b6edbd95
432f8688bb72e21939845ac7a69359ca718c6676
7bb50cbc4af78a0c8d36fdf2c141ad1330125e2f
8c74c9d1ade0fbdab5b815ddb747351b8b839641
Change-Id: Iff614260c1b1582856edb4ae7a226f2e07537698
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49045
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley