#
33388b44 |
| 23-Apr-2020 |
Matt Caswell |
Update copyright year Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11616)
|
#
b418980c |
| 16-Apr-2020 |
Dr. Matthias St. Pierre |
Swap parameters of evp_method_id() The order of the function's parameters `name_id` and `operation_id` was reverted compared to their order of appearance in the comments and assertio
Swap parameters of evp_method_id() The order of the function's parameters `name_id` and `operation_id` was reverted compared to their order of appearance in the comments and assertions. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11542)
show more ...
|
#
64f849f4 |
| 13-Apr-2020 |
Dr. Matthias St. Pierre |
Fix an assertion (and a comment) of evp_method_id() Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11542)
|
Revision tags: OpenSSL_1_1_1f |
|
#
6b1e5fa4 |
| 25-Mar-2020 |
Matt Caswell |
Put an error on the stack in the event of a fetch failure Fetch failures are a common problem and it is useful to have detailed information about what was requested in the event of a fai
Put an error on the stack in the event of a fetch failure Fetch failures are a common problem and it is useful to have detailed information about what was requested in the event of a failure. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11405)
show more ...
|
Revision tags: OpenSSL_1_1_1e |
|
#
3f7ce7f1 |
| 12-Feb-2020 |
Richard Levitte |
Refactor evp_pkey_make_provided() to do legacy to provider export Previously, evp-keymgmt_util_export_to_provider() took care of all kinds of exports of EVP_PKEYs to provider side keys,
Refactor evp_pkey_make_provided() to do legacy to provider export Previously, evp-keymgmt_util_export_to_provider() took care of all kinds of exports of EVP_PKEYs to provider side keys, be it from its legacy key or from another provider side key. This works most of the times, but there may be cases where the caller wants to be a bit more in control of what sort of export happens when. Also, when it's time to remove all legacy stuff, that job will be much easier if we have a better separation between legacy support and support of provided stuff, as far as we can take it. This changes moves the support of legacy key to provider side key export from evp-keymgmt_util_export_to_provider() to evp_pkey_make_provided(), and makes sure the latter is called from all EVP_PKEY functions that handle legacy stuff. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11074)
show more ...
|
#
e4a1d023 |
| 15-Jan-2020 |
Richard Levitte |
Modify EVP_CIPHER_is_a() and EVP_MD_is_a() to handle legacy methods too These functions would only handle provided methods, but there are cases where the caller just passes along a recei
Modify EVP_CIPHER_is_a() and EVP_MD_is_a() to handle legacy methods too 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)
show more ...
|
#
437ad983 |
| 15-Jan-2020 |
Richard Levitte |
Move the stored namemap pre-population to namemap construction Prepopulation of the stored namemap from the legacy method object database happened on first EVP fetch. However, there are
Move the stored namemap pre-population to namemap construction 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)
show more ...
|
Revision tags: OpenSSL_1_0_2u |
|
#
36fa4d8a |
| 19-Nov-2019 |
Richard Levitte |
CORE: pass the full algorithm definition to the method constructor So far, the API level method constructors that are called by ossl_method_construct_this() were passed the algorithm nam
CORE: pass the full algorithm definition to the method constructor So far, the API level method constructors that are called by ossl_method_construct_this() were passed the algorithm name string and the dispatch table and had no access to anything else. This change gives them access to the full OSSL_ALGORITHM item, thereby giving them access to the property definition. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10394)
show more ...
|
#
3d83c735 |
| 08-Nov-2019 |
Richard Levitte |
CORE: ossl_namemap_add_names(): new function to add multiple names This was originally the private add_names_to_namemap() in crypto/evp/evp_fetch.c, but made more generally useful.
CORE: ossl_namemap_add_names(): new function to add multiple names 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)
show more ...
|
Revision tags: OpenSSL_1_0_2t, OpenSSL_1_1_0l, OpenSSL_1_1_1d, OpenSSL_1_1_1c, OpenSSL_1_1_0k, OpenSSL_1_0_2s |
|
#
6a835fcf |
| 23-May-2019 |
Richard Levitte |
Replumbing: pre-populate the EVP namemap with commonly known names This adds ossl_namemap_empty(), to detect if a namemap is empty and can thereby be pre-populated. This also af
Replumbing: pre-populate the EVP namemap with commonly known names 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)
show more ...
|
#
bdbf2df2 |
| 11-Nov-2019 |
Pauli |
Properties: make query cache reference count aware. The property query cache was not reference count aware and this could cause problems if the property store removes an algorithm while
Properties: make query cache reference count aware. The property query cache was not reference count aware and this could cause problems if the property store removes an algorithm while it is being returned from an asynchronous query. This change makes the cache reference count aware and avoids disappearing algorithms. A side effect of this change is that the reference counts are now owned by the cache and store. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10408)
show more ...
|
#
0ddf74bf |
| 31-Oct-2019 |
Richard Levitte |
Final cleanup after move to leaner EVP_PKEY methods Now that KEYMGMT method pointers have moved away from the diverse methods that are used with EVP_PKEY_CTX, we no longer need to pass
Final cleanup after move to leaner EVP_PKEY methods Now that KEYMGMT method pointers have moved away from the diverse methods that are used with EVP_PKEY_CTX, we no longer need to pass special argument to evp_generic_fetch() and evp_generic_do_all(). Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10309)
show more ...
|
#
181ea366 |
| 24-Oct-2019 |
Richard Levitte |
crypto/evp/evp_fetch.c: Make it more prominent that these functions are EVP Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10257)
|
#
4dc0d81a |
| 24-Sep-2019 |
Richard Levitte |
evp_generic_do_all(): fix passing of method data 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
evp_generic_do_all(): fix passing of method data 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)
show more ...
|
#
f651c727 |
| 23-Sep-2019 |
Richard Levitte |
EVP: add name traversal functions to all fetchable types The following new functions all do the same thing; they traverse the set of names assigned to implementations of each algorithm t
EVP: add name traversal functions to all fetchable types 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)
show more ...
|
#
695d195b |
| 23-May-2019 |
Richard Levitte |
Replumbing: make it possible for providers to specify multiple names This modifies the treatment of algorithm name strings to allow multiple names separated with colons. Reviewe
Replumbing: make it possible for providers to specify multiple names 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)
show more ...
|
#
50cd4768 |
| 27-Sep-2019 |
Dr. Matthias St. Pierre |
Reorganize public header files (part 1) Rename <openssl/ossl_typ.h> to <openssl/types.h>. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/open
Reorganize public header files (part 1) Rename <openssl/ossl_typ.h> to <openssl/types.h>. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
show more ...
|
#
706457b7 |
| 27-Sep-2019 |
Dr. Matthias St. Pierre |
Reorganize local header files 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 direc
Reorganize local header files 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)
show more ...
|
#
25f2138b |
| 27-Sep-2019 |
Dr. Matthias St. Pierre |
Reorganize private crypto header files Currently, there are two different directories which contain internal header files of libcrypto which are meant to be shared internally: W
Reorganize private crypto header files 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)
show more ...
|
#
32040838 |
| 21-Sep-2019 |
Richard Levitte |
Rework cipher / digest fetching for legacy nids with multiple name support With multiple names, it's no longer viable to just grab the "first" in the set and use that to find the legacy
Rework cipher / digest fetching for legacy nids with multiple name support 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)
show more ...
|
#
7cfa1717 |
| 14-Sep-2019 |
Richard Levitte |
Modify providers that keep track of underlying algorithms With some provider implementations, there are underlying ciphers, digests and macs. For some of them, the name was retrieved fr
Modify providers that keep track of underlying algorithms 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)
show more ...
|
#
f7c16d48 |
| 14-Sep-2019 |
Richard Levitte |
In provider implemented methods, save the name number, not the name string Multiple names per implementation is already supported in the namemap, but hasn't been used yet. However, as s
In provider implemented methods, save the name number, not the name string 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)
show more ...
|
#
3ca9d210 |
| 23-Aug-2019 |
Richard Levitte |
Refactor how KEYMGMT methods get associated with other methods KEYMGMT methods were attached to other methods after those were fully created and registered, thereby creating a potential
Refactor how KEYMGMT methods get associated with other methods 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)
show more ...
|
#
c1d56231 |
| 21-Aug-2019 |
Richard Levitte |
Modify ossl_method_store_add() to accept an OSSL_PROVIDER and check for it If ossl_method_store_add() gets called with a method that already exists (i.e. the store has one with matching
Modify ossl_method_store_add() to accept an OSSL_PROVIDER and check for it If ossl_method_store_add() gets called with a method that already exists (i.e. the store has one with matching provider, nid and properties), that method should not be stored. We do this check inside ossl_method_store_add() because it has all the locking required to do so safely. Fixes #9561 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9650)
show more ...
|
#
b1d40ddf |
| 21-Aug-2019 |
Richard Levitte |
Modify ossl_method_store_add() to handle reference counting Because this function affects the reference count on failure (the call to impl_free() does this), it may as well handle increm
Modify ossl_method_store_add() to handle reference counting Because this function affects the reference count on failure (the call to impl_free() does this), it may as well handle incrementing it as well to indicate the extra reference in the method store. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9650)
show more ...
|