summaryrefslogtreecommitdiffstats
path: root/crypto/core_namemap.c
AgeCommit message (Collapse)Author
2020-10-15Rename OPENSSL_CTX prefix to OSSL_LIB_CTXDr. Matthias St. Pierre
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)
2020-07-29namemap: fix threading issuePauli
The locking was too fine grained when adding entries to a namemap. Refactored the working code into unlocked functions and call these with appropriate locking. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12545)
2020-06-21namemap: change ossl_namemap_empty() to do what the documentation says.Pauli
The function is documented as returning 1 when passed a NULL argument. Instead it core dumps. Added a unit test for this. Additionally, a performance improvement is incorporated. The namemap max_number field is only ever compared against zero and incremented. The zero comparison grabs a lock specifically for this check. This change uses TSAN operations instead if they are available. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12181)
2020-04-28Rename FIPS_MODE to FIPS_MODULERichard Levitte
This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-23Update copyright yearMatt Caswell
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11616)
2020-01-17Modify EVP_CIPHER_is_a() and EVP_MD_is_a() to handle legacy methods tooRichard Levitte
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)
2020-01-16Move the stored namemap pre-population to namemap constructionRichard Levitte
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)
2019-11-29CORE: ossl_namemap_add_names(): new function to add multiple namesRichard Levitte
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)
2019-11-22Core: allow NULL argument to stored_namemap_free().Pauli
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10488)
2019-11-20Replumbing: pre-populate the EVP namemap with commonly known namesRichard Levitte
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)
2019-10-03Replumbing: make it possible for providers to specify multiple namesRichard Levitte
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)
2019-09-28Reorganize private crypto header filesDr. Matthias St. Pierre
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)
2019-09-19In provider implemented methods, save the name number, not the name stringRichard Levitte
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)
2019-06-24OSSL_NAMEMAP: make names case insensitiveRichard Levitte
Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8967)
2019-06-24Replumbing: add support for multiple names per algorithmRichard Levitte
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)
2019-05-12Create internal number<->name mapping APIRichard Levitte
This can be used as a general name to identity map. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8878)