I had a rewrite of the decrepit ciphers (CAST and Blowfish) to use
CRYPTO_{load,store}_u32_be and drop the old macros, but this is probably
not worth the effort to review. Instead, just fix the type in the macro.
Bug: 516
Change-Id: I1cdecc16f6108a6235f90cf9c2198bc797c6716e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54985
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Bug: 516
Change-Id: Iba2014da414658c08e42e0993912fa73848832d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54945
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
MSVC 2022's C4191 warns on most function pointer casts. Fix and/or
silence them:
connect.c is an unavoidable false positive. We're casting the pointer to
the correct type. The problem was that the caller is required to first
cast it to the wrong type in OpenSSL's API, due to the BIO_callback_ctrl
calling convention. Suppress it.
LHASH_OF(T) and STACK_OF(T)'s defintions also have a false positive.
Suppress that warning. Calling the functions through the casted types
would indeed be UB, but we don't do that. We use them as goofy
type-erased types. The problem is there is no function pointer
equivalent of void*. (Using actual void* instead trips a GCC warning.)
The sk_sort instance is a true instance of UB. The problem is qsort
lacks a context parameter. I've made sk_sort call qsort_s on _MSC_VER,
to silence the warning. Ideally we'd fix it on other platforms, but
qsort_r and qsort_s are a disaster. See
https://stackoverflow.com/a/39561369
Fixed: 495
Change-Id: I0dca80670c74afaa03fc5c8fd7059b4cfadfac72
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53005
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
These definitions are to get access to getaddrinfo() and gmtime_r()
when using glibc. This in turn conflicts with other places (which
would have these things in their libc anyway) where using these
feature flags turns off C11 functionality we would like to use.
Bug:490
Change-Id: I66fdb7292cda788df19508d99e7303ed0d4f4bdd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52545
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The free callbacks can assume their inputs are non-NULL. They're only
called from BIOs of the corresponding method, which means the BIO must
exist. Also new callbacks that leave everything zero-initialized are
no-ops and can be omitted.
This removes the weird thing where the built-in free functions were
fallible. Although the int return is still necessary for compatibility
with external BIOs.
Change-Id: I91e2101efc7c77c703cb649df1490bc9f515f0fd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48846
Reviewed-by: Adam Langley <agl@google.com>
gai_strerror is one of the Windows functions which behaves differently
whether UNICODE is defined. See
https://docs.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes
Call gai_strerrorA so that we behave consistently in both modes. This
fixes the build failure in
https://chromium-review.googlesource.com/c/chromium/src/+/2613519.
It also fixes a type error in the connect BIO (built but not used in
Chromium), which wasn't noticed because ERR_add_error_data is a variadic
function and untyped. (The type error won't go out of bounds because
we're interpreting a NUL-terminated WCHAR* as a NUL-terminated char*.
The string will be misinterpreted, but it still will be terminated
either at the NUL WCHAR or, more likely, the upper zero byte of the
first Latin-1 character in the string.)
The ERR_add_error_data call raises the question of which of our char*
strings are UTF-8 and which are the POSIX locale / Windows code page
(when those are not also UTF-8). This CL doesn't address this and only
fixes the character width error. Realistically, calling code tosses
char* to printf so often that non-UTF-8 locales are probably a lost
cause. (Although right now we do not transform any OS error strings, so
tossing them to printf works fine. The outputs of functions like
ASN1_STRING_to_UTF8, not so much.)
Change-Id: Ie789730658829bde90022605ade2c86b8a65c3de
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44964
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL synchronizes bio->next_bio and ssl->rbio with a variety of
callbacks, so BIO_copy_next_retry worked. We do not, so attempting to
flush the BIO crashed.
The SSL BIO is a compatibility hack and intentionally much more limited,
so start by just copying things from the right BIO directly. Add a basic
unit test for SSL BIOs. If we need to, we can implement a more complex
synchronization later.
Additionally reject reconfiguring an SSL BIO because that will leak the
object right now.
Change-Id: I724c95ab6f1a3a1aa1889b0483c81ce3bdc534ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43424
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Bob Beck
Adam Langley