This results in one change, which is the comparison function goes from:
typedef char *OPENSSL_STRING;
static int sk_strcmp(const OPENSSL_STRING *a,
const OPENSSL_STRING *b);
which is:
static int sk_strcmp(char *const *a, char *const *b)
into:
static int sk_strcmp(const char **a, const char **b)
Neither is correct (both consts should be there), but switching the
defintion is necessary to attach the 'const' to 'char' itself. Otherwise
it wouldn't see through the typedef. Fixing the rest of the calling
convention will finish the job. Plan there is, when
I00d13c949a535c0d60873fe4ba2e5604bb585cca lands, I'll switch Envoy to
call that. Then we should be clear to const-correct the callback.
(While STACK_OF(OPENSSL_STRING) is used externally, nothing external
touches the comparison function.)
Bug: 498
Change-Id: I77bdf2a72b2553bf9409a1d39326890ed5c3582c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53008
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@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>
Update-Note: ".example.com" as an input DNS name will no longer match
"www.example.com" in a certificate. (Note this does not impact wildcard
certificates. Rather, it removes a non-standard "reverse wildcard" that
OpenSSL implemented.)
Fixed: 463
Change-Id: I627e1bd00b8e4b810e9bb756f424f6230a99496e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50726
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Always enable X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS and never enable
X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS.
Update-Note: BoringSSL will no longer accept wildcard patterns like
*www.example.com or www*.example.com. (It already did not accept
ww*w.example.com.) X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS will also be
ignored and can no longer be used to allow foo.bar.example.com to match
*.example.com.
Fixes: 462
Change-Id: I004e087bf70f4c3f249235cd864d9e19cc9a5102
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50705
Reviewed-by: Adam Langley <agl@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>
Subsequent CLs will add some fuzzers, etc., that'll help with catching
this.
Change-Id: I10a8e4b2f23ffd07b124e725c1f7454e7ea6f2dd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49025
Reviewed-by: Adam Langley <agl@google.com>
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>
This imports part of the fix for CVE-2021-3712, commits
d9d838ddc0ed083fb4c26dd067e71aad7c65ad16,
5f54e57406ca17731b9ade3afd561d3c652e07f2,
23446958685a593d4d9434475734b99138902ed2,
and bb4d2ed4091408404e18b3326e3df67848ef63d0 from upstream. The
others will be imported in follow-up CLs.
Change-Id: Ic35aeb3895935ee94b82a295efade32782e8d1bc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49005
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Additionally decorate ipv4_from_asc and ipv6_from_asc with their
array lengths.
Bug: 419
Change-Id: I2bce182ac260b071f076434deadab4096d29b2b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48265
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@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>
David Benjamin
Giorgio Marinelli
Adam Langley