mirror of
https://github.com/openssl/openssl.git
synced 2025-01-30 14:01:55 +08:00
19ad1e9d37
The TODO described a case where a legacy derive operation is called, but the peer key is provider based. In practice this will almost never be a problem. We should never end up in our own legacy EVP_PKEY_METHOD implementations if no ENGINE has been configured. If an ENGINE has been configured then we we will be using a third party EVP_PKEY_METHOD implementation and public APIs will be used to obtain the key data from the peer key so there will be no "reaching inside" the pkey. There is a theoretical case where a third party ENGINE wraps our own internal EVP_PKEY_METHODs using EVP_PKEY_meth_find() or EVP_PKEY_meth_get0(). For these cases we just ensure all our EVP_PKEY_METHODs never reach "inside" the implementation of a peer key. We can never assume that it is a legacy key. Fixes #14399 Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14555) |
||
|---|---|---|
| .. | ||
| build.info | ||
| dh_ameth.c | ||
| dh_asn1.c | ||
| dh_backend.c | ||
| dh_check.c | ||
| dh_depr.c | ||
| dh_err.c | ||
| dh_gen.c | ||
| dh_group_params.c | ||
| dh_kdf.c | ||
| dh_key.c | ||
| dh_lib.c | ||
| dh_local.h | ||
| dh_meth.c | ||
| dh_pmeth.c | ||
| dh_prn.c | ||
| dh_rfc5114.c | ||