These functions would only handle provided methods, but there are
cases where the caller just passes along a received method without
knowing the underlying method tech, so might pass along a legacy
method. We therefore need to have them handle this case as well so
they don't cause any unnecessary surprises.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10845)
Prepopulation of the stored namemap from the legacy method object
database happened on first EVP fetch. However, there are moments when
that prepopulation needs to happen even though no fetching has been
performed yet. We therefore move pre-population to happen when the
namemap is constructed.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10846)
This was originally the private add_names_to_namemap() in
crypto/evp/evp_fetch.c, but made more generally useful.
To make for more consistent function naming, ossl_namemap_add() and
ossl_namemap_add_n() are renamed to ossl_namemap_add_name() and
ossl_namemap_add_name_n().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
This adds ossl_namemap_empty(), to detect if a namemap is empty and
can thereby be pre-populated.
This also affects the way legacy NIDs are looked up in
evp_cipher_from_dispatch() and evp_md_from_dispatch(). Instead of
trying to find the NID directly, look up the legacy method structure
and grab the NID from there. The reason is that NIDs can be aliases
for other NIDs, which looks like a clash even if wasn't really one.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8984)
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)
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)
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)
Algorithms may have multiple names, as seen in the legacy names
database. We need to support that as well.
This implementations modifies ossl_namemap to support multiple names
for the same identifier.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8967)
