OSSL_provider_init() gets another output parameter, holding a pointer
to a provider side context. It's entirely up to the provider to
define the context and what it's being used for. This pointer is
passed back to other provider functions, typically the provider global
get_params and set_params functions, and also the diverse algorithm
context creators, and of course, the teardown function.
With this, a provider can be instantiated more than once, or be
re-loaded as the case may be, while maintaining instance state.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8848)
We reuse test/provider_internal_test.c and test/p_test.c,
and get it loaded one more time via the configuration file
test/provider_internal_test.conf
To support different platform standards regarding module
extensions, we generate test/provider_internal_test.conf
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8549)
The OSSL_PARAM attribute names |buffer| and |buffer_size| may lead to
confusion, as they may make some think that the memory pointed at is
an intermediate memory are. This is not generally the case, so we
rename |buffer| and |buffer_size| to |data| and |data_size|
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8451)
Two tests are added, one that tests the internal API, the other tests
the public API. Those two tests both test the same provider, which
acts both as a built-in provider and as a loadable provider module.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8287)
