Copyright year updates


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

OSSL_PROVIDER_load_ex

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

Fix a potential memory leak in crypto/provider_child.c

Fix issue #20063.
CLA: trivial

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org

Fix a potential memory leak in crypto/provider_child.c

Fix issue #20063.
CLA: trivial

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

show more ...

For child libctx / provider, don't count self-references in parent

In child library contexts, which contain child "clones" of the
providers the application has in store, one of these chi

For child libctx / provider, don't count self-references in parent

In child library contexts, which contain child "clones" of the
providers the application has in store, one of these children will
always be the provider that creates the child library context; let's
call them self-refering child providers.

For these self-refering child providers, we don't increment the parent
provider reference count, nor do we free the parent provider, as those
become self defeating and hinder the teardown and unloading process
when the application cleans up.

For non self-refering child providers, we must retain this propagation
of reference count to the parent, so that aren't torn down too early,
i.e. when there's still a "foreign" reference (fetched algorithm).

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

show more ...

Update copyright year

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Release: yes

Refactor OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA

This refactors OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA. The assorted
objects to be managed by OSSL_LIB_CTX are hardcoded and are in

Refactor OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA

This refactors OSSL_LIB_CTX to avoid using CRYPTO_EX_DATA. The assorted
objects to be managed by OSSL_LIB_CTX are hardcoded and are initialized
eagerly rather than lazily, which avoids the need for locking on access
in most cases.

Fixes #17116.

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

show more ...

Stop receiving child callbacks in a child libctx when appropriate

We should stop receiving child callbacks if we're about to free up
the child libctx. Otherwise we can get callbacks when

Stop receiving child callbacks in a child libctx when appropriate

We should stop receiving child callbacks if we're about to free up
the child libctx. Otherwise we can get callbacks when the libctx is half
freed up.

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

show more ...

Remove the isinited variable from child_prov_globals

This variable might have made sense at some point but it not longer does
so. It was being used to check whether we are still initing

Remove the isinited variable from child_prov_globals

This variable might have made sense at some point but it not longer does
so. It was being used to check whether we are still initing or not. If we
are still initing then the assumption was that we already hold the lock.
That assumption was untrue. We need to always take the lock.

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

show more ...

Don't attempt to deactive child providers if we don't need to

If a provider doesn't have any child providers then there is no need
to attempt to remove them - so we should not do so. Thi

Don't attempt to deactive child providers if we don't need to

If a provider doesn't have any child providers then there is no need
to attempt to remove them - so we should not do so. This removes some
potentialy thread races.

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

show more ...

Fix a race in ossl_provider_add_to_store()

If two threads both attempt to load the same provider at the same time,
they will first both check to see if the provider already exists. If it

Fix a race in ossl_provider_add_to_store()

If two threads both attempt to load the same provider at the same time,
they will first both check to see if the provider already exists. If it
doesn't then they will both then create new provider objects and call the
init function. However only one of the threads will be successful in adding
the provider to the store. For the "losing" thread we should still return
"success", but we should deinitialise and free the no longer required
provider object, and return the object that exists in the store.

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

show more ...

Merge ossl_provider_activate() and ossl_provider_activate_child()

These 2 functions have become so close to each other that they may as well
be just one function.

Reviewed-by: P

Merge ossl_provider_activate() and ossl_provider_activate_child()

These 2 functions have become so close to each other that they may as well
be just one function.

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

show more ...

Set use_fallbacks to zero when we add a provider to the store

Update use_fallbacks to zero when we add a provider to the store rather
than when we activate it. Its only at the point that

Set use_fallbacks to zero when we add a provider to the store

Update use_fallbacks to zero when we add a provider to the store rather
than when we activate it. Its only at the point that we add it to the store
that it is actually usable and visible to other threads.

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

show more ...

Remove flag_couldbechild

Now that a provider is no longer put into the store until after it has
been activated we don't need flag_couldbechild any more. This flag was
used to indicat

Remove flag_couldbechild

Now that a provider is no longer put into the store until after it has
been activated we don't need flag_couldbechild any more. This flag was
used to indicate whether a provider was eligible for conversion into a
child provider or not. This was only really interesting for predefined
providers that were automatically created.

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

show more ...

Add a new provider to the store only after we activate it

Rather than creating the provider, adding to the store and then activating
it, we do things the other way around, i.e. activate

Add a new provider to the store only after we activate it

Rather than creating the provider, adding to the store and then activating
it, we do things the other way around, i.e. activate first and then add to
the store. This means that the activation should occur before other threads
are aware of the provider.

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

show more ...

Ensure mirroring of properties works for subsequent updates

If the global properties are updated after a provider with a child libctx
has already started we need to make sure those updat

Ensure mirroring of properties works for subsequent updates

If the global properties are updated after a provider with a child libctx
has already started we need to make sure those updates are mirrored in
that child.

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

show more ...

Add a callback for providers to know about global properties changes

Where a child libctx is in use it needs to know what the current global
properties are.

Reviewed-by: Paul Da

Add a callback for providers to know about global properties changes

Where a child libctx is in use it needs to know what the current global
properties are.

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

show more ...

Fix a use-after-free in the child provider code

If the child provider context data gets cleaned up before all usage of
providers has finished then a use-after-free can occur. We change t

Fix a use-after-free in the child provider code

If the child provider context data gets cleaned up before all usage of
providers has finished then a use-after-free can occur. We change the
priority of this data so that it gets freed later.

Fixes #15284

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

show more ...

Init the child providers immediately on creation of the child libctx

We were deferring the initial creation of the child providers until the
first fetch. This is a carry over from an ear

Init the child providers immediately on creation of the child libctx

We were deferring the initial creation of the child providers until the
first fetch. This is a carry over from an earlier iteration of the child
lib ctx development and is no longer necessary. In fact we need to init
the child providers immediately otherwise not all providers quite init
correctly.

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

show more ...

Don't convert pre-existing providers into children

If a provider explicitly loads another provider into a child libctx where
it wasn't previously loaded then we don't start treating it l

Don't convert pre-existing providers into children

If a provider explicitly loads another provider into a child libctx where
it wasn't previously loaded then we don't start treating it like a child
if the parent libctx subsequently loads the same provider.

Fixes #14925

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

show more ...

Add support for child provider to up_ref/free their parent

If the ref counts on a child provider change, then this needs to be
reflected in the parent so we add callbacks to do this.

Add support for child provider to up_ref/free their parent

If the ref counts on a child provider change, then this needs to be
reflected in the parent so we add callbacks to do this.

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

show more ...

Register callbacks with core for child provider creation/deletion

By adding callbacks to the core this will enable (in future commits) the
ability to add/remove child providers as the pr

Register callbacks with core for child provider creation/deletion

By adding callbacks to the core this will enable (in future commits) the
ability to add/remove child providers as the providers are added/removed
from the parent libctx.

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

show more ...

Add the concept of a child OSSL_LIB_CTX

Add a child OSSL_LIB_CTX that will mirror the providers loaded into the
parent libctx. This is useful for providers that want to use algorithms

Add the concept of a child OSSL_LIB_CTX

Add a child OSSL_LIB_CTX that will mirror the providers loaded into the
parent libctx. This is useful for providers that want to use algorithms
from other providers and just need to inherit the providers used by the
application.

Fixes #14925

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

show more ...