Defined out MUTEX attributes not available on NonStop SPT Threads.

Standard Posix Threads (SPT) Threads are an older separate branch of
pthreads that do not support some of the capabilit

Defined out MUTEX attributes not available on NonStop SPT Threads.

Standard Posix Threads (SPT) Threads are an older separate branch of
pthreads that do not support some of the capabilities in the current
Posix User Threads (PUT).

The change also includes a rename of the close field of OSSL_STORE_LOADER
which was causing preprocessor conflicts.

Fixes #15885

Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15886)

show more ...

Update copyright year

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14801)

Always check CRYPTO_LOCK_{read,write}_lock

Some functions that lock things are void, so we just return early.

Also make ossl_namemap_empty return 0 on error. Updated the docs, and

Always check CRYPTO_LOCK_{read,write}_lock

Some functions that lock things are void, so we just return early.

Also make ossl_namemap_empty return 0 on error. Updated the docs, and added
some code to ossl_namemap_stored() to handle the failure, and updated the
tests to allow for failure.

Fixes: #14230

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14238)

show more ...

Use OPENSSL_init_crypto(OPENSSL_INIT_BASE_ONLY, NULL) in libcrypto

Calling OPENSSL_init_crypto(0, NULL) is a no-op and will
not properly initialize thread local handling.

Only t

Use OPENSSL_init_crypto(OPENSSL_INIT_BASE_ONLY, NULL) in libcrypto

Calling OPENSSL_init_crypto(0, NULL) is a no-op and will
not properly initialize thread local handling.

Only the calls that are needed to initialize thread locals
are kept, the rest of the no-op calls are removed.

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14497)

show more ...

Run the withlibctx.pl script

Automatically rename all instances of _with_libctx() to _ex() as per
our coding style.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged fro

Run the withlibctx.pl script

Automatically rename all instances of _with_libctx() to _ex() as per
our coding style.

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

show more ...

STORE: Change all error recording to use ERR_raise() / ERR_raise_data()

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)

STORE: Add the base functions to support provider based loaders

This includes fixing a bug that could only be discovered when no
loaders were registered.

Reviewed-by: Shane Lont

STORE: Add the base functions to support provider based loaders

This includes fixing a bug that could only be discovered when no
loaders were registered.

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)

show more ...

STORE: Add missing function OSSL_STORE_LOADER_set_open_with_libctx()

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)

Add X509 related libctx changes.

- In order to not add many X509_XXXX_with_libctx() functions the libctx and propq may be stored in the X509 object via a call to X509_new_with_libctx().

Add X509 related libctx changes.

- In order to not add many X509_XXXX_with_libctx() functions the libctx and propq may be stored in the X509 object via a call to X509_new_with_libctx().
- Loading via PEM_read_bio_X509() or d2i_X509() should pass in a created cert using X509_new_with_libctx().
- Renamed some XXXX_ex() to XXX_with_libctx() for X509 API's.
- Removed the extra parameters in check_purpose..
- X509_digest() has been modified so that it expects a const EVP_MD object() and then internally it does the fetch when it needs to (via ASN1_item_digest_with_libctx()).
- Added API's that set the libctx when they load such as X509_STORE_new_with_libctx() so that the cert chains can be verified.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12153)

show more ...

Update copyright year

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

OSSL_STORE: Make it possible to attach an OSSL_STORE to an opened BIO

This capability existed internally, and is now made public.

Reviewed-by: David von Oheimb <david.von.oheimb@sie

OSSL_STORE: Make it possible to attach an OSSL_STORE to an opened BIO

This capability existed internally, and is now made public.

Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/11756)

show more ...

Reorganize local header files

Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
direc

Reorganize local header files

Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like

'*_lcl.h', '*_local.h', or '*_int.h'

This commit changes the different suffixes to '*_local.h' uniformly.

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

show more ...

Reorganize private crypto header files

Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:

W

Reorganize private crypto header files

Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:

While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.

To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:

#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'

This commit moves the private crypto headers from

'crypto/include/internal' to 'include/crypto'

As a result, the include directives become unambiguous

#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'

hence the superfluous '_int.h' suffixes can be stripped.

The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.

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

show more ...

Following the license change, modify the boilerplates in crypto/store/

[skip ci]

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pul

Following the license change, modify the boilerplates in crypto/store/

[skip ci]

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7821)

show more ...

STORE: Add the possibility to search for specific information

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2688)

STORE: Add the possibility to specify an expected info type

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2688)

Update copyright year

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

Revert the crypto "global lock" implementation

Conceptually, this is a squashed version of:

Revert "Address feedback"

This reverts commit 75551e07bd2339dfea06ef1d31

Revert the crypto "global lock" implementation

Conceptually, this is a squashed version of:

Revert "Address feedback"

This reverts commit 75551e07bd2339dfea06ef1d31d69929e13a4495.

and

Revert "Add CRYPTO_thread_glock_new"

This reverts commit ed6b2c7938ec6f07b15745d4183afc276e74c6dd.

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: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)

show more ...

Add CRYPTO_thread_glock_new

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

This has been added to avoid the situation where some host ctype.h functions
return true for characters > 127. I.e. they are allowing extended ASCII
characters through which then cause probl

This has been added to avoid the situation where some host ctype.h functions
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: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4102)

show more ...

Fixups for STORE commit

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

STORE: fix possible memory leak

If scheme is NULL, the allocated res is leaked

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/38

STORE: fix possible memory leak

If scheme is NULL, the allocated res is leaked

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3841)

show more ...

STORE: Make sure the loader to be registered is complete

Most of the loader function pointers are crucial, they must be defined
unconditionally. Therefore, let's make sure OSSL_STORE_re

STORE: Make sure the loader to be registered is complete

Most of the loader function pointers are crucial, they must be defined
unconditionally. Therefore, let's make sure OSSL_STORE_register_loader
refuses to register incomplete loaders

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3805)

show more ...

STORE: simplify store_loader_cmp()

We have already made sure that the loader scheme isn't NULL, so
checking if they are NULL or not when comparing registered loaders
is redundant. W

STORE: simplify store_loader_cmp()

We have already made sure that the loader scheme isn't NULL, so
checking if they are NULL or not when comparing registered loaders
is redundant. We still soft assert it, just to be entirely sure.

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3805)

show more ...

STORE: add ENGINE information to loaders

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)