Typos in doc/man* will be fixed in a different commit.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20910)
Fixes#20710
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20745)
The provider functions OSSL_FUNC_keymgmt_import_types() and
OSSL_FUNC_keymgmt_export_types() do not get the provider context passed.
This makes it difficult for providers to implement these functions unless
its a static implementation returning a truly constant OSSL_PARAM array.
Some providers may have a need to return an OSSL_PARAM array that is
dependent on the provider configuration, or anything else that is contained
in its provider context.
Add extended variants of these functions that get the provider context passed.
The functions should still return a static and constant OSSL_PARAM array, but
may use the provider context to select the array to return dependent on its
context. The returned array must be constant at least until the provider is
unloaded.
Providers can implement only the original functions, or only the extended
functions, or both. Implementing at least one of those functions is required
if also the respective OSSL_FUNC_keymgmt_import() or OSSL_FUNC_keymgmt_export()
function is implemented. If an extended function is available, it is called by
evp_keymgmt_import_types() or evp_keymgmt_export_types(), otherwise the original
function is called.
This makes the code backward compatible. Existing providers will only implement
the original functions, so these functions will continued to be called.
Newer providers can choose to implement the extended functions, and thus can
benefit from the provider context being passed to the implementation.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20255)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17740)
One was related to probing for the combination of signature and hash
algorithm together. This is currently not easily possible. The TODO(3.0)
is converted to a normal comment and I've raised the problem as issue
number #14885 as something to resolve post 3.0.
The other TODO was a hard coded limit on the number of groups that could
be registered. This has been amended so that there is no limit.
Fixes#14333
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14886)
This allows making the signature operations return different
settable params when the context is initialized with
EVP_DigestSign/VerifyInit.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14338)
Without these hooks, if the TLS provider isn't matched in the fetch cache, a test
failure will occur in the TLS API tests. Without allowing import and export, an
existing key can not move to a new key manager even if it is really the same.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14126)
The keydata argument of OSSL_FUNC_keymgmt_has() should be read-only.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13200)
We do the same thing for the "get1" version. In reality this has broader
use than just TLS (it can also be used in CMS), and "encodedpoint" only
makes sense when you are talking about EC based algorithms.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13105)
Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix,
e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER.
The OPENSSL_CTX type stands out a little by using a different prefix.
For consistency reasons, this type is renamed to OSSL_LIB_CTX.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12621)
Note that with this commit the optional parameter is introduced, but
libssl still ignores it.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13018)
We check that EVP_default_properties_is_fips_enabled() is working even
before other function calls have auto-loaded the config file.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12567)
The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all
functions which are dispatched between the core and providers.
This change includes in particular all up- and downcalls, i.e., the
dispatched functions passed from core to provider and vice versa.
- OSSL_core_ -> OSSL_FUNC_core_
- OSSL_provider_ -> OSSL_FUNC_core_
For operations and their function dispatch tables, the following convention
is used:
Type | Name (evp_generic_fetch(3)) |
---------------------|-----------------------------------|
operation | OSSL_OP_FOO |
function id | OSSL_FUNC_FOO_FUNCTION_NAME |
function "name" | OSSL_FUNC_foo_function_name |
function typedef | OSSL_FUNC_foo_function_name_fn |
function ptr getter | OSSL_FUNC_foo_function_name |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12222)
