Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7569)

(cherry picked from commit 5c8b7b4caa0faedb69277063a7c6b3a8e56c6308)

Fixes: #5899
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5911)

The warning reads "[cast] may cause misaligned access". Even though
this can be application-supplied pointer, misaligned access shouldn't
happen, because structure type is "encoded" into data itself, and
application would customarily pass correctly aligned pointer. But
there is no harm in resolving the warning...
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5894)

Almost all *alloc failures now set an error code.
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5842)

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Conceptually, this is a squashed version of:

    Revert "Address feedback"

    This reverts commit 75551e07.

and

    Revert "Add CRYPTO_thread_glock_new"

    This reverts commit ed6b2c79.

But there were some intervening commits that made neither revert apply
cleanly, so instead do it all as one shot.

The crypto global locks were an attempt to cope with the awkward
POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE"
section) indicates that the expected usage is to have the prefork handler
lock all "global" locks, and the parent and child handlers release those
locks, to ensure that forking happens with a consistent (lock) state.
However, the set of functions available in the child process is limited
to async-signal-safe functions, and pthread_mutex_unlock() is not on
the list of async-signal-safe functions!  The only synchronization
primitives that are async-signal-safe are the semaphore primitives,
which are not really appropriate for general-purpose usage.

However, the state consistency problem that the global locks were
attempting to solve is not actually a serious problem, particularly for
OpenSSL.  That is, we can consider four cases of forking application
that might use OpenSSL:

(1) Single-threaded, does not call into OpenSSL in the child (e.g.,
the child calls exec() immediately)

For this class of process, no locking is needed at all, since there is
only ever a single thread of execution and the only reentrancy is due to
signal handlers (which are themselves limited to async-signal-safe
operation and should not be doing much work at all).

(2) Single-threaded, calls into OpenSSL after fork()

The application must ensure that it does not fork() with an unexpected
lock held (that is, one that would get unlocked in the parent but
accidentally remain locked in the child and cause deadlock).  Since
OpenSSL does not expose any of its internal locks to the application
and the application is single-threaded, the OpenSSL internal locks
will be unlocked for the fork(), and the state will be consistent.
(OpenSSL will need to reseed its PRNG in the child, but that is
an orthogonal issue.)  If the application makes use of locks from
libcrypto, proper handling for those locks is the responsibility of
the application, as for any other locking primitive that is available
for application programming.

(3) Multi-threaded, does not call into OpenSSL after fork()

As for (1), the OpenSSL state is only relevant in the parent, so
no particular fork()-related handling is needed.  The internal locks
are relevant, but there is no interaction with the child to consider.

(4) Multi-threaded, calls into OpenSSL after fork()

This is the case where the pthread_atfork() hooks to ensure that all
global locks are in a known state across fork() would come into play,
per the above discussion.  However, these "calls into OpenSSL after
fork()" are still subject to the restriction to async-signal-safe
functions.  Since OpenSSL uses all sorts of locking and libc functions
that are not on the list of safe functions (e.g., malloc()), this
case is not currently usable and is unlikely to ever be usable,
independently of the locking situation.  So, there is no need to
go through contortions to attempt to support this case in the one small
area of locking interaction with fork().

In light of the above analysis (thanks @davidben and @achernya), go
back to the simpler implementation that does not need to distinguish
"library-global" locks or to have complicated atfork handling for locks.
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4872)

It's argued that /WX allows to keep better focus on new code, which
motivates its comeback...
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4721)

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4294)

CLA: trivial
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4298)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4217)

return true for characters > 127.  I.e. they are allowing extended ASCII
characters through which then cause problems.  E.g. marking superscript '2' as
a number then causes the common (ch - '0') conversion to number to fail
miserably.  Likewise letters with diacritical marks can also cause problems.

If a non-ASCII character set is being used (currently only EBCDIC), it is
adjusted for.

The implementation uses a single table with a bit for each of the defined
classes.  These functions accept an int argument and fail for
values out of range or for characters outside of the ASCII set.  They will
work for both signed and unsigned character inputs.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4102)

Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3740)

bss_dgram.c is deferred until later due to ongoing discussions.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3740)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3286)

We also change the enum type to an int.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3286)

The existing BIO_lookup() wraps a call to getaddrinfo and provides an
abstracted capability to lookup addresses based on socket type and family.
However it provides no ability to lookup based on protocol. Normally,
when dealing with TCP/UDP this is not required. However getaddrinfo (at
least on linux) never returns SCTP addresses unless you specifically ask
for them in the protocol field. Therefore BIO_lookup_ex() is added which
provides the protocol field.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3286)

Fix some comments too
[skip ci]
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3069)

Private hstrerror was introduced to address linking problem on HP-UX,
but truth be told conemporary systems, HP-UX included, wouldn't come
to that call, they would use getaddrinfo and gai_strerror, while
gethostbyname and h_errno are there to serve legacy systems. Since
legacy systems are naturally disappearing breed, we can as well just
let user interpret number.

GH#2816
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2092)
(cherry picked from commit 46766d003666da5f90346da7e6d09e109355f5c6)

Certain functions are automatically called during auto-deinit in order
to deallocate resources. However, if we have never entered a function which
marks lib crypto as inited then they never get called. This can happen if
the user only ever makes use of a small sub-set of functions that don't hit
the auto-init code.

This commit ensures all such resources deallocated by these functions also
init libcrypto when they are initially allocated.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NBen Laurie <ben@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

That way, we have a way to check if the init function was successful
or not.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

"configured on the local system". Whatever that means. Example that is biting
me is loopback has ::1 as an address, but the network interface is v4 only.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

RT4378
Reviewed-by: NRichard Levitte <levitte@openssl.org>

There were some unchecked calls to OPENSSL_strdup().
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Document thread-safe lock creation
Reviewed-by: NRichard Levitte <levitte@openssl.org>

- Missing checks for allocation failure.
- releasing memory in few missing error paths
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

BIO_ADDR_new() calls OPENSSL_zalloc() which can fail - but the return
value is not checked.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/952)

Some locks were not being properly cleaned up during close down.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

This reverts commit 620d540b.
It wasn't reviewed.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

On VMS, the C compiler can work with 32-bit and 64-bit pointers, and
the command line determines what the initial pointer size shall be.

However, there is some functionality that only works with 32-bit
pointers.  In this case, it's gethostbyname(), getservbyname() and
accompanying structures, so we need to make sure that we define our
own pointers as 32-bit ones.

Furthermore, there seems to be a bug in VMS C netdb.h, where struct
addrinfo is always defined with 32-bit pointers no matter what, but
the functions handling it are adapted to the initial pointer size.
This leads to pointer size warnings when compiling with
/POINTER_SIZE=64.  The workaround is to force struct addrinfo to be
the 64-bit variant if the initial pointer size is 64.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

'proto' wasn't properly used as a fallback in all appropriate cases.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

This silences the memory sanitizer. All fields were already correctly
initialized but the struct padding wasn't, causing an uninitialized read
warning.
Reviewed-by: NTim Hudson <tjh@openssl.org>

When OPENSSL_NO_ASYNC is set, make ASYNC_{un,}block_pause() do nothing.
This prevents md_rand.c from failing to build. Probably better to do it
this way than to wrap every instance in an explicit #ifdef.

A bunch of new socket code got added to a new file crypto/bio/b_addr.c.
Make it all go away if OPENSSL_NO_SOCK is defined.

Allow configuration with no-ripemd, no-ts, no-ui
We use these for the UEFI build.

Also remove the 'Really???' comment from no-err and no-locking. We use
those too.

We need to drop the crypto/engine directory from the build too, and also
set OPENSSL_NO_ENGINE
Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NTim Hudson <tjh@openssl.org>