You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
05aa8790ac
The provider context structure is made to include the following information: - The core provider handle (first argument to the provider init function). This handle is meant to be used in all upcalls that need it. - A library context, used for any libcrypto calls that need it, done in the provider itself. Regarding the library context, that's generally only needed if the provider makes any libcrypto calls, i.e. is linked with libcrypto. That happens to be the case for all OpenSSL providers, but is applicable for other providers that use libcrypto internally as well. The normal thing to do for a provider init function is to create its own library context. For a provider that's meant to become a dynamically loadable module, this is what MUST be done. However, we do not do that in the default provider; it uses the library context associated with the core provider handle instead. This is permissible, although generally discouraged, as long as the provider in question is guaranteed to be built-in, into libcrypto or into the application that uses it. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11803) |
3 years ago | |
|---|---|---|
| .. | ||
| common | 3 years ago | |
| fips | 3 years ago | |
| implementations | 3 years ago | |
| build.info | 3 years ago | |
| defltprov.c | 3 years ago | |
| legacyprov.c | 3 years ago | |
| nullprov.c | 3 years ago | |