This is the EVP operation that corresponds to creating direct RSA, DH
and DSA keys and set their numbers, to then assign them to an EVP_PKEY,
but done entirely using an algorithm agnostic EVP interface.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10187)
Now that we have an EVP namemap containing all aliases that providers
know about for any given algorithm, it is possible that an application
attempts to look up a digest or a cipher via EVP_get_digestbyname() or
EVP_get_cipherbyname() with an algorithm name that is unknown to the
legacy method database. Therefore we extend those functions to
additionally check the aliases in the namemap when searching for a
method in the event that our initial lookup attempt fails.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10324)
Because the algorithm to use is decided already when creating an
EVP_PKEY_CTX regardless of how it was created, it turns out that it's
unnecessary to provide the SIGNATURE method explicitly, and rather
always have it be fetched implicitly.
This means fewer changes for applications that want to use new
signature algorithms / implementations.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10303)
Because the algorithm to use is decided already when creating an
EVP_PKEY_CTX regardless of how it was created, it turns out that it's
unnecessary to provide the KEYEXCH method explicitly, and rather
always have it be fetched implicitly.
This means fewer changes for applications that want to use new key
exchange algorithms / implementations.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10305)
With provided algorithms, the library context is ever present, so of
course it should be specified alongside the algorithm name and
property query string.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10308)
There is a vagueness around how the provider data (algorithm name and
property query string) is initialized in the presence of an engine.
This change modifies this slightly so that the algorithm name for use
with providers is never set if the initilization was given an engine.
This makes it easier for other functions to simply check ctx->algorithm
to see if the context is meant to be used for strictly legacy stuff or
not.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10308)
Otherwise, should this function be called more than once on the same
EVP_PKEY_CTX, we get double free issues.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10292)
RSA-PSS keys use the same internal structure as RSA keys but do not
allow accessing it through EVP_PKEY_get0_RSA. This commit changes that
behavior.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10217)
This leaves minimal implementations of EVP_blake2b512 and EVP_blake2s256,
that are now only there to provide a name for implicit fetches.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9075)
It may be that the OSSL_PARAM array we used for getting parameter
values for a key had a few too many entries. These are detected by
their return_size == 0. Before making second export call, we prune
away these items so we only ask for parameters that exist.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10190)
Method data was passed down as provider to ossl_algorithm_do_all(),
which causes trouble as soon a it's non-NULL. Pass it via the data
structure instead.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/9979)
The following new functions all do the same thing; they traverse
the set of names assigned to implementations of each algorithm type:
EVP_MD_names_do_all(), EVP_CIPHER_names_do_all(),
EVP_MAC_names_do_all(), EVP_KEYMGMT_names_do_all(),
EVP_KEYEXCH_names_do_all(), EVP_KDF_names_do_all(),
EVP_SIGNATURE_names_do_all()
We add a warning to the documentation of EVP_CIPHER_name() and
EVP_MD_name(), as they aren't suitable to use with multiple-name
implementation.
We also remove EVP_MAC_name() and evp_KDF_name(), as they serve no
useful purpose.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/9979)
This adds the missing functions that should be common for all
fetchable EVP sub-APIs:
EVP_KEYMGMT_is_a(), EVP_KEYMGMT_do_all_provided(), EVP_KEYEXCH_is_a(),
EVP_KEYEXCH_do_all_provided(), EVP_KDF_is_a(), EVP_MD_is_a(),
EVP_SIGNATURE_do_all_provided(), EVP_SIGNATURE_is_a().
This also renames EVP_MD_do_all_ex(), EVP_CIPHER_do_all_ex(),
EVP_KDF_do_all_ex(), EVP_MAC_do_all_ex() to change '_ex'
to '_provided'.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/9979)
This control command should never be used with provided methods, but
since this is publically available, someone might still make the
mistake. We make sure it returns 1 so as not to be overly
disruptive.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10163)
This works as much as possible EVP_PKEY_CTX_new_id(), except it takes
data that's relevant for providers, algorithm name and property query
string instead of NID and engine.
Additionally, if EVP_PKEY_CTX_new() or EVP_PKEY_CTX_new_id() was
called, the algorithm name in the EVP_PKEY context will be set to the
short name of the given NID (explicit or the one of the given
EVP_PKEY), thereby giving an easier transition from legacy methods to
provided methods.
The intent is that operations will use this information to fetch
provider methods implicitly as needed.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10184)
We need to pass the SSL3 Master Secret down to the provider code in order
for SSLv3 to work correctly.
Fixes#10182
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10186)
This leaves minimal implementations of EVP_md2, EVP_md4, EVP_md5 and
EVP_mdc2, that are now only there to provide a name for implicit fetches.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10164)
If we remove these, the functions EVP_get_digestbyname() and
EVP_get_cipherbyname() will stop working entirely, and it's too early
to criple them yet.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10176)
EVP_Cipher() would return whatever ctx->cipher->ccipher() returned
with no regard for historical semantics.
We change this to first look if there is a ctx->cipher->ccipher(), and
in that case we treat the implementation as one with a custom cipher,
and "translate" it's return value like this: 0 => -1, 1 => outl, where
|outl| is the output length.
If there is no ctx->cipher->ccipher, we treat the implementation as
one without a custom cipher, call ctx->cipher->cupdate or
ctx->cipher->cfinal depending on input, and return whatever they
return (0 or 1).
Furthermore, we add a small hack in EVP_CIPHER_flags() to check if the
cipher is a provided one, and add EVP_CIPH_FLAG_CUSTOM_CIPHER to the
flags to be returned if there is a cipher->ccipher. That way,
provided implementations never have to set that flag themselves, all
they need to do is to include a OSSL_FUNC_CIPHER_CIPHER function.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10137)
Prior to OpenSSL 3.0 EVP_Digest[Sign|Verify|Update were just macros for
EVP_DigestUpdate. They are now separate functions. Unfortunately some
code assumes that EVP_Digest[Sign|Verify]Update is interchangeable with
EVP_DigestUpdate. For example the dgst app uses an MD bio which always
calls EVP_DigestUpdate(). However the dgst app supports signing instead
of digesting and may initialise with EVP_DigestSignInit_ex() instead of
just EVP_DigestInit().
We now detect these differences and redirect to the correct function
where appropriate.
Fixes#10114
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10116)
There is no need for us to be diving inside the EVP_MD_CTX in the
implementation of an MD BIO. We can just use public APIs. By doing this
certain calls (such as getting the MD out of the BIO were not working
correctly) where providers are in use.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10116)
From providers/{common,default,legacy}/ to providers/implementations/
However, providers/common/digests/digest_common.c stays where it is,
because it's support code rather than an implementation.
To better support all kinds of implementations with common code, we
add the library providers/libcommon.a. Code that ends up in this
library must be FIPS agnostic.
While we're moving things around, though, we move digestscommon.h
from providers/common/include/internal to providers/common/include/prov,
thereby starting on a provider specific include structure, which
follows the line of thoughts of the recent header file reorganization.
We modify the affected '#include "internal/something.h"' to
'#include "prov/something.h"'.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
We put almost everything in these internal static libraries:
libcommon Block building code that can be used by all
our implementations, legacy and non-legacy
alike.
libimplementations All non-legacy algorithm implementations and
only them. All the code that ends up here is
agnostic to the definitions of FIPS_MODE.
liblegacy All legacy implementations.
libnonfips Support code for the algorithm implementations.
Built with FIPS_MODE undefined. Any code that
checks that FIPS_MODE isn't defined must end
up in this library.
libfips Support code for the algorithm implementations.
Built with FIPS_MODE defined. Any code that
checks that FIPS_MODE is defined must end up
in this library.
The FIPS provider module is built from providers/fips/*.c and linked
with libimplementations, libcommon and libfips.
The Legacy provider module is built from providers/legacy/*.c and
linked with liblegacy, libcommon and libcrypto.
If module building is disabled, the object files from liblegacy and
libcommon are added to libcrypto and the Legacy provider becomes a
built-in provider.
The Default provider module is built-in, so it ends up being linked
with libimplementations, libcommon and libnonfips. For libcrypto in
form of static library, the object files from those other libraries
are simply being added to libcrypto.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
Also added blanks lines after declarations in a couple of places.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9916)
Even thought the underlying calls might return something other than 0
or 1, EVP_CIPHER_CTX_ctrl() and EVP_MD_CTX_ctrl() were made to only
return those values regardless. That behaviour was recently lost, so
we need to restore it.
Fixes#10106
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10108)
This leaves minimal implementations of EVP_md5_sha1, which is now only
there to provide a name for implicit fetches.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9076)
This leaves minimal implementations of EVP_sha* and EVP_shake*, which
is now only there to provide a name for implicit fetches.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10059)
This modifies the treatment of algorithm name strings to allow
multiple names separated with colons.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/8985)
EVP_DigestInit_ex forced following of the legacy path if ctx->pctx is
set (meaning we've actually been called via EVP_DigestSignInit_ex).
There is some code in the legacy path that calls the
EVP_PKEY_CTRL_DIGESTINIT ctrl on the pctx. Not going down the legacy path
if ctx->pctx is set means that ctrl message will neve get sent. However,
it turns out that all algs that understand that ctrl also set the
EVP_MD_CTX_FLAG_NO_INIT flag which forces legacy anyway. Therefore the
ctx->pctx check is not required and can be removed.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10082)
Otherwise a mem leak can occur since EVP_MD_free() calls
EVP_MD_CTX_reset() which then clears the contents of the ctx.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
This resets the fields of the EVP_MD_CTX and means we can no longer
make calls using the EVP_MD_CTX, such as to query parameters.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
If doing an EVP_DigestSign*() or EVP_DigestVerify*() operation we use
the embedded pctx for communication with the provider. Any MD params need
to use that ctx instead.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
This flag is still relevant even for non-legacy code so we should check
it where appropriate.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10013)
So far, these two funtions have depended on legacy EVP_CIPHER
implementations to be able to do their work. This change adapts them
to work with provided implementations as well, in one of two possible
ways:
1. If the implementation's set_asn1_parameters or get_asn1_parameters
function pointers are non-NULL, this is a legacy implementation,
and that function is called.
2. Otherwise, if the cipher doesn't have EVP_CIPH_FLAG_CUSTOM_ASN1
set, the default AlgorithmIdentifier parameter code in libcrypto
is executed.
3. Otherwise, if the cipher is a provided implementation, the ASN1
type structure is converted to a DER blob which is then passed to
the implementation as a parameter (param_to_asn1) or the DER blob
is retrieved from the implementation as a parameter and converted
locally to a ASN1_TYPE (asn1_to_param).
With this, the old flag EVP_CIPH_FLAG_DEFAULT_ASN1 has become
irrelevant and is simply ignored.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10008)
All instances of EVP_*_CTX_gettable_params functions have been renamed
to EVP_*_gettable_ctx_params. Except for the EVP_MD ones which were changed
already.
These functions do not take EVP_*_CTX arguments so their prior naming was
misleading.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10052)
Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
using PCC and KDSA instructions.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10004)
EVP_MD_CTX_gettable_params() and EVP_MD_CTX_settable_params() were
confusingly named because they did not take an EVP_MD_CTX parameter.
In addition we add the functions EVP_MD_gettable_ctx_params() and
EVP_MD_settable_ctx_params() which do the same thing but are passed
an EVP_MD object instead.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9998)
With multiple names, it's no longer viable to just grab the "first" in
the set and use that to find the legacy NID. Instead, all names for
an algorithm must be checked, and if we encounter more than one NID
asssociated with those names, we consider it an error and make that
method unloadable.
This ensures that all methods that do have an internal NID associated
will get that NID in their structure, thereby ensuring that other
parts of libcrypto that haven't gone away from using NIDs for
comparison will continue to work as expected.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9969)
It either makes the flow of control simpler and more obvious, or it is
just a "cleanup" so that the editing scripts will find and fixup things.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9441)
With some provider implementations, there are underlying ciphers,
digests and macs. For some of them, the name was retrieved from the
method, but since the methods do not store those any more, we add
different mechanics.
For code that needs to pass on the name of a cipher or diges via
parameters, we simply locally store the name that was used when
fetching said cipher or digest. This will ensure that any underlying
code that needs to fetch that same cipher or digest does so with the
exact same name instead of any random name from the set of names
associated with the algorithm.
For code that needs to check what kind of algorithm was passed, we
provide EVP_{type}_is_a(), that returns true if the given method has
the given name as one of its names.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
This caused a SEGV inside tls13_enc() when using chacha_poly.
The tls code assigns the iv_length to a size_t (even though it is an int).
This is actually really bad since it could be -1, which will then trash the iv buffer.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/9890)
The output C code was made to use ERR_func_error_string() to see if a
string table was already loaded or not. Since this function returns
NULL always, this check became useless.
Change it to use ERR_reason_error_string() instead, as there's no
reason to believe we will get rid of reason strings, ever.
To top it off, we rebuild all affected C sources.
Fixes#9756
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9756)
It is undefined behaviour to send NULL as either the src, or dest params
in memcpy.
In pkey_kdf.c we had a check to ensure that the src address is non-NULL.
However in some situations it is possible that the dest address could also
be NULL. Specifically in the case where the datalen is 0 and we are using
a newly allocated BUF_MEM.
We add a check of datalen to avoid the undefined behaviour.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9868)
Make sure we pass the provider side ctx and not the libcrypto side ctx.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9865)
An EVP_PKEY can be used for multiple different algorithm operations.
Only one can be used at a time, so we move those into a union.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9753)
We add new functions for getting parameters and discovering the gettable
and settable parameters. We also make EVP_PKEY_CTX_get_signature_md() a
function and implement it in terms of the new functions.
This enables applications to discover the set of parameters that are
supported for a given algorithm implementation.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9753)
This makes EVP_PKEY_sign and EVP_PKEY_sign_init provider aware. It
also introduces the new type EVP_SIGNATURE to represent signature
algorithms. This also automatically makes the EVP_Sign* APIs provider
aware because they use EVP_Digest* (which is already provider aware)
and EVP_PKEY_sign(_init) under the covers.
At this stage there are no signature algorithms in any providers. That
will come in the following commits.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9753)
BUF_MEM_grow() returns the passed length, but also zero on error. If
the passed length was zero, an extra check to see if a returned zero
was an error or not is needed.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9662)
pkey_kdf_ctrl_str() has to do the same kind of special treatment as
pkey_kdf_ctrl() does.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9662)
Undo the caching scheme, pass through most controls as parameters, except
for SEED and INFO, where we keep supporting adding data through additional
ctrl calls by collecting the data, and only passing it to the EVP_KDF
before calling its derive function.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9662)
If the passed string length is zero, the function computes the string length
from the passed string.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9760)
This function re-implements EVP_CIPHER_meth_free(), but has a name that
isn't encumbered by legacy EVP_CIPHER construction functionality.
We also refactor most of EVP_CIPHER_meth_new() into an internal
evp_cipher_new() that's used when creating fetched methods.
EVP_CIPHER_meth_new() and EVP_CIPHER_meth_free() are rewritten in terms of
evp_cipher_new() and EVP_CIPHER_free(). This means that at any time, we can
deprecate all the EVP_CIPHER_meth_ functions with no harmful consequence.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9758)
This function re-implements EVP_MD_meth_free(), but has a name that
isn't encumbered by legacy EVP_MD construction functionality.
We also refactor most of EVP_MD_meth_new() into an internal
evp_md_new() that's used when creating fetched methods.
EVP_MD_meth_new() and EVP_MD_meth_free() are rewritten in terms of
evp_md_new() and EVP_MD_free(). This means that at any time, we can
deprecate all the EVP_MD_meth_ functions with no harmful consequence.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9758)
KEYMGMT methods were attached to other methods after those were fully
created and registered, thereby creating a potential data race, if two
threads tried to create the exact same method at the same time.
Instead of this, we change the method creating function to take an
extra data parameter, passed all the way from the public fetching
function. In the case of EVP_KEYEXCH, we pass all the necessary data
that evp_keyexch_from_dispatch() needs to be able to fetch the
appropriate KEYMGMT method on the fly.
Fixes#9592
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9678)
Use the header file internal/cryptlib.h instead.
Remove checks for OPENSSL_NO_ASM and I386_ONLY
in cryptlib.c, to match the checks in other
places where OPENSSL_ia32cap_P is used and
assumed to be initialized.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/9688)
