Fix remaining provider config settings to be decisive in value

There is one remaining config setting for providers, soft_load, which is
enabled when provided in a config, regardless of i

Fix remaining provider config settings to be decisive in value

There is one remaining config setting for providers, soft_load, which is
enabled when provided in a config, regardless of its value. Augment it
to require a decisive value 1/0, yes/no, on/off, true/false, as we've
recently done for the activate setting.

Also, since it wasn't previously documented, add docs for it.

Fixes #23105

Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23111)

show more ...

Detect and prevent recursive config parsing

If a malformed config file is provided such as the following:

openssl_conf = openssl_init
[openssl_init]
providers = provider_sec

Detect and prevent recursive config parsing

If a malformed config file is provided such as the following:

openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
= provider_sect

The config parsing library will crash overflowing the stack, as it
recursively parses the same provider_sect ad nauseum.

Prevent this by maintaing a list of visited nodes as we recurse through
referenced sections, and erroring out in the event we visit any given
section node more than once.

Note, adding the test for this revealed that our diagnostic code
inadvertently pops recorded errors off the error stack because
provider_conf_load returns success even in the event that a
configuration parse failed. The call path to provider_conf_load has been
updated in this commit to address that shortcoming, allowing recorded
errors to be visibile to calling applications.

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

show more ...

Make the activate setting more intuitive

Currently, a provider is activated from our config file using the
activate parameter. However, the presence of the config parameter is
suffi

Make the activate setting more intuitive

Currently, a provider is activated from our config file using the
activate parameter. However, the presence of the config parameter is
sufficient to trigger activation, leading to a counterintuitive
situation in which setting "activate = 0" still activates the provider

Make activation more intuitive by requiring that activate be set to one
of yes|true|1 to trigger activation. Any other value, as well as
omitting the parameter entirely, prevents activation (and also maintains
backward compatibility.

It seems a bit heavyweight to create a test specifically to validate the
plurality of these settings. Instead, modify the exiting openssl config
files in the test directory to use variants of these settings, and
augment the default.cnf file to include a provider section that is
explicitly disabled

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22906)

show more ...

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)

Stop raising ERR_R_MALLOC_FAILURE in most places

Since OPENSSL_malloc() and friends report ERR_R_MALLOC_FAILURE, and
at least handle the file name and line number they are called from,

Stop raising ERR_R_MALLOC_FAILURE in most places

Since OPENSSL_malloc() and friends report ERR_R_MALLOC_FAILURE, and
at least handle the file name and line number they are called from,
there's no need to report ERR_R_MALLOC_FAILURE where they are called
directly, or when SSLfatal() and RLAYERfatal() is used, the reason
`ERR_R_MALLOC_FAILURE` is changed to `ERR_R_CRYPTO_LIB`.

There were a number of places where `ERR_R_MALLOC_FAILURE` was reported
even though it was a function from a different sub-system that was
called. Those places are changed to report ERR_R_{lib}_LIB, where
{lib} is the name of that sub-system.
Some of them are tricky to get right, as we have a lot of functions
that belong in the ASN1 sub-system, and all the `sk_` calls or from
the CRYPTO sub-system.

Some extra adaptation was necessary where there were custom OPENSSL_malloc()
wrappers, and some bugs are fixed alongside these changes.

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

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

Refactor: a separate func for provider activation from config

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

Refactor: a separate func for provider activation from config

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

show more ...

Correctly activate the provider in OSSL_PROVIDER_try_load

If during OSSL_PROVIDER_try_load() we attempt to load a provider, but
adding to the store gives back a different provider, then

Correctly activate the provider in OSSL_PROVIDER_try_load

If during OSSL_PROVIDER_try_load() we attempt to load a provider, but
adding to the store gives back a different provider, then we need to
ensure this different provider has its activation count increased.

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

Add return value NULL checks that were missing

Issues located by Brian Carpenter of Geeknik's Farm.

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

Add return value NULL checks that were missing

Issues located by Brian Carpenter of Geeknik's Farm.

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

show more ...

Add locking for the provider_conf.c

Avoid races where 2 threads attempt to configure activation of providers
at the same time. E.g. via an explicit and an implict load of the config

Add locking for the provider_conf.c

Avoid races where 2 threads attempt to configure activation of providers
at the same time. E.g. via an explicit and an implict load of the config
file at the same time.

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

show more ...

When activating providers via config check we've not already activated them

We skip the activation if we already configured them.

Fixes #16250

Reviewed-by: Tomas Mraz <toma

When activating providers via config check we've not already activated them

We skip the activation if we already configured them.

Fixes #16250

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

show more ...

Ensure any default_properties still apply even in the event of a provider load failure

We don't treat a failure to load a provider as a fatal error. If it is fatal then
we give up attemp

Ensure any default_properties still apply even in the event of a provider load failure

We don't treat a failure to load a provider as a fatal error. If it is fatal then
we give up attempting to load the config file - including reading any default
properties. Additionally if an attempt has been made to load a provider then we
disable fallback loading.

Fixes #16166

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

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

make struct provider_info_st a full type

Create the OSSL_PROVIDER_INFO to replace struct provider_info_st.

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <to

make struct provider_info_st a full type

Create the OSSL_PROVIDER_INFO to replace struct provider_info_st.

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

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

Instantiate configuration supplied providers when we need them

If provider specified in a config file are not "activated" then we defer
instantiating the provider object until it is actu

Instantiate configuration supplied providers when we need them

If provider specified in a config file are not "activated" then we defer
instantiating the provider object until it is actually needed.

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 NCONF_get0_libctx()

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

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

Add the ability for ex_data to have a priority

Where an object has multiple ex_data associated with it, then we free that
ex_data in order of priority (high priority first).

Rev

Add the ability for ex_data to have a priority

Where an object has multiple ex_data associated with it, then we free that
ex_data in order of priority (high priority first).

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

show more ...

Store the list of activated providers in the libctx

The provider config module was storing the list of activated providers
in a global variable. However, because different libctxs can ea

Store the list of activated providers in the libctx

The provider config module was storing the list of activated providers
in a global variable. However, because different libctxs can each load
providers via config files we need to keep the list of activated providers
separate and in the libctx.

Partially fixes #15030

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

show more ...