Fix a memleak in the FIPS provider

If the DRBG is used within the scope of the FIPS OSSL_provider_init
function then it attempts to register a thread callback via c_thread_start.
How

Fix a memleak in the FIPS provider

If the DRBG is used within the scope of the FIPS OSSL_provider_init
function then it attempts to register a thread callback via c_thread_start.
However the implementation of c_thread_start assumed that the provider's
provctx was already present. However because OSSL_provider_init is still
running it was actually NULL. This means the thread callback fail to work
correctly and a memory leak resulted.

Instead of having c_thread_start use the provctx as the callback argument
we change the definition of c_thread_start to have an explicit callback
argument to use.

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

show more ...

Add RUN_ONCE support to zlib init

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

Update copyright year

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

include/crypto: add a few missing #pragma once directives

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from http

include/crypto: add a few missing #pragma once directives

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/14096)

show more ...

Always ensure we hold ctx->lock when calling CRYPTO_get_ex_data()

Otherwise we can get data races.

Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/ope

Always ensure we hold ctx->lock when calling CRYPTO_get_ex_data()

Otherwise we can get data races.

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

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 ...