mirror of
https://github.com/openssl/openssl.git
synced 2024-11-27 05:21:51 +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) |
||
|---|---|---|
| .. | ||
| asm | ||
| curve448 | ||
| build.info | ||
| curve25519.c | ||
| ec2_oct.c | ||
| ec2_smpl.c | ||
| ec_ameth.c | ||
| ec_asn1.c | ||
| ec_backend.c | ||
| ec_check.c | ||
| ec_curve.c | ||
| ec_cvt.c | ||
| ec_deprecated.c | ||
| ec_err.c | ||
| ec_key.c | ||
| ec_kmeth.c | ||
| ec_lib.c | ||
| ec_local.h | ||
| ec_mult.c | ||
| ec_oct.c | ||
| ec_pmeth.c | ||
| ec_print.c | ||
| ecdh_kdf.c | ||
| ecdh_ossl.c | ||
| ecdsa_ossl.c | ||
| ecdsa_sign.c | ||
| ecdsa_vrf.c | ||
| eck_prn.c | ||
| ecp_mont.c | ||
| ecp_nist.c | ||
| ecp_nistp224.c | ||
| ecp_nistp256.c | ||
| ecp_nistp521.c | ||
| ecp_nistputil.c | ||
| ecp_nistz256_table.c | ||
| ecp_nistz256.c | ||
| ecp_oct.c | ||
| ecp_s390x_nistp.c | ||
| ecp_smpl.c | ||
| ecx_backend.c | ||
| ecx_backend.h | ||
| ecx_key.c | ||
| ecx_meth.c | ||
| ecx_s390x.c | ||