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)
The change to a more configuration based approach to enable FIPS mode
operation highlights a shortcoming in the default should do something
approach we've taken for bad configuration files.
Currently, a bad configuration file will be automatically loaded and
once the badness is detected, it will silently stop processing the
configuration and continue normal operations. This is good for remote
servers, allowing changes to be made without bricking things. It's bad
when a user thinks they've configured what they want but got something
wrong and it still appears to work.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16171)
Different providers will give different results, and we need to test
them all.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9398)
Neil Horman
Pauli
Richard Levitte