2019-02-09 00:01:56 +08:00
|
|
|
/*
|
2021-01-28 20:54:57 +08:00
|
|
|
* Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.
|
2019-02-09 00:01:56 +08:00
|
|
|
*
|
|
|
|
* Licensed under the Apache License 2.0 (the "License"). You may not use
|
|
|
|
* this file except in compliance with the License. You can obtain a copy
|
|
|
|
* in the file LICENSE in the source distribution or at
|
|
|
|
* https://www.openssl.org/source/license.html
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stddef.h>
|
2019-09-28 06:45:46 +08:00
|
|
|
#include <openssl/types.h>
|
2019-02-09 00:01:56 +08:00
|
|
|
#include <openssl/evp.h>
|
|
|
|
#include <openssl/core.h>
|
|
|
|
#include "internal/cryptlib.h"
|
|
|
|
#include "internal/thread_once.h"
|
|
|
|
#include "internal/property.h"
|
|
|
|
#include "internal/core.h"
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
#include "internal/provider.h"
|
2019-05-04 18:56:32 +08:00
|
|
|
#include "internal/namemap.h"
|
2020-08-09 16:06:52 +08:00
|
|
|
#include "internal/property.h"
|
2019-09-28 06:45:40 +08:00
|
|
|
#include "crypto/evp.h" /* evp_local.h needs it */
|
|
|
|
#include "evp_local.h"
|
2019-02-09 00:01:56 +08:00
|
|
|
|
2019-05-23 09:36:21 +08:00
|
|
|
#define NAME_SEPARATOR ':'
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void evp_method_store_free(void *vstore)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
ossl_method_store_free(vstore);
|
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static void *evp_method_store_new(OSSL_LIB_CTX *ctx)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-05-01 18:02:43 +08:00
|
|
|
return ossl_method_store_new(ctx);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static const OSSL_LIB_CTX_METHOD evp_method_store_method = {
|
2019-10-24 23:04:01 +08:00
|
|
|
evp_method_store_new,
|
|
|
|
evp_method_store_free,
|
2019-02-09 00:01:56 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Data to be passed through ossl_method_construct() */
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st {
|
2020-10-15 17:55:50 +08:00
|
|
|
OSSL_LIB_CTX *libctx;
|
2019-02-09 00:01:56 +08:00
|
|
|
OSSL_METHOD_CONSTRUCT_METHOD *mcm;
|
2019-10-24 23:04:01 +08:00
|
|
|
int operation_id; /* For get_evp_method_from_store() */
|
|
|
|
int name_id; /* For get_evp_method_from_store() */
|
|
|
|
const char *names; /* For get_evp_method_from_store() */
|
|
|
|
const char *propquery; /* For get_evp_method_from_store() */
|
2020-08-29 15:46:24 +08:00
|
|
|
|
2021-03-03 01:15:32 +08:00
|
|
|
unsigned int flag_construct_error_occurred : 1;
|
2020-08-29 15:46:24 +08:00
|
|
|
|
2021-03-16 21:14:43 +08:00
|
|
|
void *(*method_from_algorithm)(int name_id, const OSSL_ALGORITHM *,
|
|
|
|
OSSL_PROVIDER *);
|
2019-02-09 00:01:56 +08:00
|
|
|
int (*refcnt_up_method)(void *method);
|
|
|
|
void (*destruct_method)(void *method);
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Generic routines to fetch / create EVP methods with ossl_method_construct()
|
|
|
|
*/
|
2020-10-15 17:55:50 +08:00
|
|
|
static void *alloc_tmp_evp_method_store(OSSL_LIB_CTX *ctx)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-05-01 18:02:43 +08:00
|
|
|
return ossl_method_store_new(ctx);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void dealloc_tmp_evp_method_store(void *store)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
if (store != NULL)
|
|
|
|
ossl_method_store_free(store);
|
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static OSSL_METHOD_STORE *get_evp_method_store(OSSL_LIB_CTX *libctx)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2020-10-15 17:55:50 +08:00
|
|
|
return ossl_lib_ctx_get_data(libctx, OSSL_LIB_CTX_EVP_METHOD_STORE_INDEX,
|
|
|
|
&evp_method_store_method);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
2020-04-14 06:12:48 +08:00
|
|
|
* To identify the method in the EVP method store, we mix the name identity
|
|
|
|
* with the operation identity, under the assumption that we don't have more
|
2019-10-24 23:04:01 +08:00
|
|
|
* than 2^24 names or more than 2^8 operation types.
|
2019-06-07 17:44:08 +08:00
|
|
|
*
|
|
|
|
* The resulting identity is a 32-bit integer, composed like this:
|
|
|
|
*
|
|
|
|
* +---------24 bits--------+-8 bits-+
|
|
|
|
* | name identity | op id |
|
|
|
|
* +------------------------+--------+
|
|
|
|
*/
|
2020-04-17 01:10:14 +08:00
|
|
|
static uint32_t evp_method_id(int name_id, unsigned int operation_id)
|
2019-06-07 17:44:08 +08:00
|
|
|
{
|
2020-04-14 06:12:48 +08:00
|
|
|
if (!ossl_assert(name_id > 0 && name_id < (1 << 24))
|
|
|
|
|| !ossl_assert(operation_id > 0 && operation_id < (1 << 8)))
|
2019-06-07 17:44:08 +08:00
|
|
|
return 0;
|
|
|
|
return ((name_id << 8) & 0xFFFFFF00) | (operation_id & 0x000000FF);
|
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static void *get_evp_method_from_store(OSSL_LIB_CTX *libctx, void *store,
|
2019-10-24 23:04:01 +08:00
|
|
|
void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
2019-02-09 00:01:56 +08:00
|
|
|
void *method = NULL;
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
int name_id;
|
|
|
|
uint32_t meth_id;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* get_evp_method_from_store() is only called to try and get the method
|
|
|
|
* that evp_generic_fetch() is asking for, and the operation id as well
|
|
|
|
* as the name or name id are passed via methdata.
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
*/
|
|
|
|
if ((name_id = methdata->name_id) == 0) {
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
2019-05-23 09:36:21 +08:00
|
|
|
const char *names = methdata->names;
|
|
|
|
const char *q = strchr(names, NAME_SEPARATOR);
|
|
|
|
size_t l = (q == NULL ? strlen(names) : (size_t)(q - names));
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
|
|
|
|
if (namemap == 0)
|
|
|
|
return NULL;
|
2019-05-23 09:36:21 +08:00
|
|
|
name_id = ossl_namemap_name2num_n(namemap, names, l);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (name_id == 0
|
2020-04-17 01:10:14 +08:00
|
|
|
|| (meth_id = evp_method_id(name_id, methdata->operation_id)) == 0)
|
2019-02-09 00:01:56 +08:00
|
|
|
return NULL;
|
|
|
|
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
if (store == NULL
|
2019-10-24 23:04:01 +08:00
|
|
|
&& (store = get_evp_method_store(libctx)) == NULL)
|
2019-05-05 14:42:21 +08:00
|
|
|
return NULL;
|
|
|
|
|
2019-11-11 09:17:32 +08:00
|
|
|
if (!ossl_method_store_fetch(store, meth_id, methdata->propquery,
|
|
|
|
&method))
|
|
|
|
return NULL;
|
2019-02-09 00:01:56 +08:00
|
|
|
return method;
|
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static int put_evp_method_in_store(OSSL_LIB_CTX *libctx, void *store,
|
2019-10-24 23:04:01 +08:00
|
|
|
void *method, const OSSL_PROVIDER *prov,
|
|
|
|
int operation_id, const char *names,
|
|
|
|
const char *propdef, void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
2019-05-05 14:42:21 +08:00
|
|
|
OSSL_NAMEMAP *namemap;
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
int name_id;
|
|
|
|
uint32_t meth_id;
|
2019-05-23 09:36:21 +08:00
|
|
|
size_t l = 0;
|
2019-03-21 01:51:29 +08:00
|
|
|
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* put_evp_method_in_store() is only called with an EVP method that was
|
|
|
|
* successfully created by construct_method() below, which means that
|
|
|
|
* all the names should already be stored in the namemap with the same
|
|
|
|
* numeric identity, so just use the first to get that identity.
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
*/
|
2019-05-23 09:36:21 +08:00
|
|
|
if (names != NULL) {
|
|
|
|
const char *q = strchr(names, NAME_SEPARATOR);
|
|
|
|
|
|
|
|
l = (q == NULL ? strlen(names) : (size_t)(q - names));
|
|
|
|
}
|
|
|
|
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
if ((namemap = ossl_namemap_stored(libctx)) == NULL
|
2019-05-23 09:36:21 +08:00
|
|
|
|| (name_id = ossl_namemap_name2num_n(namemap, names, l)) == 0
|
2020-04-17 01:10:14 +08:00
|
|
|
|| (meth_id = evp_method_id(name_id, operation_id)) == 0)
|
2019-03-21 01:51:29 +08:00
|
|
|
return 0;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
if (store == NULL
|
2019-10-24 23:04:01 +08:00
|
|
|
&& (store = get_evp_method_store(libctx)) == NULL)
|
2019-02-09 00:01:56 +08:00
|
|
|
return 0;
|
|
|
|
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
return ossl_method_store_add(store, prov, meth_id, propdef, method,
|
2019-08-21 15:58:10 +08:00
|
|
|
methdata->refcnt_up_method,
|
|
|
|
methdata->destruct_method);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
|
|
|
* The core fetching functionality passes the name of the implementation.
|
|
|
|
* This function is responsible to getting an identity number for it.
|
|
|
|
*/
|
2019-11-19 16:55:56 +08:00
|
|
|
static void *construct_evp_method(const OSSL_ALGORITHM *algodef,
|
2019-10-24 23:04:01 +08:00
|
|
|
OSSL_PROVIDER *prov, void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* This function is only called if get_evp_method_from_store() returned
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
* NULL, so it's safe to say that of all the spots to create a new
|
|
|
|
* namemap entry, this is it. Should the name already exist there, we
|
2019-11-09 07:18:05 +08:00
|
|
|
* know that ossl_namemap_add_name() will return its corresponding
|
|
|
|
* number.
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
*/
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
2020-10-15 17:55:50 +08:00
|
|
|
OSSL_LIB_CTX *libctx = ossl_provider_libctx(prov);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
2019-11-19 16:55:56 +08:00
|
|
|
const char *names = algodef->algorithm_names;
|
2019-11-09 07:18:05 +08:00
|
|
|
int name_id = ossl_namemap_add_names(namemap, 0, names, NAME_SEPARATOR);
|
2020-08-29 15:46:24 +08:00
|
|
|
void *method;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
2019-05-23 09:36:21 +08:00
|
|
|
if (name_id == 0)
|
|
|
|
return NULL;
|
2020-08-29 15:46:24 +08:00
|
|
|
|
2021-03-16 21:14:43 +08:00
|
|
|
method = methdata->method_from_algorithm(name_id, algodef, prov);
|
2020-08-29 15:46:24 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Flag to indicate that there was actual construction errors. This
|
|
|
|
* helps inner_evp_generic_fetch() determine what error it should
|
|
|
|
* record on inaccessible algorithms.
|
|
|
|
*/
|
|
|
|
if (method == NULL)
|
2021-03-03 01:15:32 +08:00
|
|
|
methdata->flag_construct_error_occurred = 1;
|
2020-08-29 15:46:24 +08:00
|
|
|
|
|
|
|
return method;
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void destruct_evp_method(void *method, void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
methdata->destruct_method(method);
|
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void *
|
2020-10-15 17:55:50 +08:00
|
|
|
inner_evp_generic_fetch(OSSL_LIB_CTX *libctx, int operation_id,
|
2019-10-24 23:04:01 +08:00
|
|
|
int name_id, const char *name,
|
|
|
|
const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
2021-03-16 21:14:43 +08:00
|
|
|
const OSSL_ALGORITHM *algodef,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
2019-10-24 23:04:01 +08:00
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
OSSL_METHOD_STORE *store = get_evp_method_store(libctx);
|
2020-01-15 08:10:42 +08:00
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
uint32_t meth_id = 0;
|
2019-02-09 00:01:56 +08:00
|
|
|
void *method = NULL;
|
2020-08-29 15:46:24 +08:00
|
|
|
int unsupported = 0;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
2020-08-29 15:46:24 +08:00
|
|
|
if (store == NULL || namemap == NULL) {
|
2020-10-17 13:07:41 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, ERR_R_PASSED_INVALID_ARGUMENT);
|
2019-04-18 18:23:21 +08:00
|
|
|
return NULL;
|
2020-08-29 15:46:24 +08:00
|
|
|
}
|
2019-04-18 18:23:21 +08:00
|
|
|
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
|
|
|
* If there's ever an operation_id == 0 passed, we have an internal
|
|
|
|
* programming error.
|
|
|
|
*/
|
2020-08-29 15:46:24 +08:00
|
|
|
if (!ossl_assert(operation_id > 0)) {
|
2020-10-17 13:07:41 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, ERR_R_INTERNAL_ERROR);
|
2019-06-07 17:44:08 +08:00
|
|
|
return NULL;
|
2020-08-29 15:46:24 +08:00
|
|
|
}
|
2019-06-07 17:44:08 +08:00
|
|
|
|
|
|
|
/*
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
* If we have been passed neither a name_id or a name, we have an
|
|
|
|
* internal programming error.
|
|
|
|
*/
|
2020-08-29 15:46:24 +08:00
|
|
|
if (!ossl_assert(name_id != 0 || name != NULL)) {
|
2020-10-17 13:07:41 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, ERR_R_INTERNAL_ERROR);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
return NULL;
|
2020-08-29 15:46:24 +08:00
|
|
|
}
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
|
|
|
|
/* If we haven't received a name id yet, try to get one for the name */
|
|
|
|
if (name_id == 0)
|
|
|
|
name_id = ossl_namemap_name2num(namemap, name);
|
|
|
|
|
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* If we have a name id, calculate a method id with evp_method_id().
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
*
|
2019-10-24 23:04:01 +08:00
|
|
|
* evp_method_id returns 0 if we have too many operations (more than
|
|
|
|
* about 2^8) or too many names (more than about 2^24). In that case,
|
|
|
|
* we can't create any new method.
|
2020-08-29 15:46:24 +08:00
|
|
|
* For all intents and purposes, this is an internal error.
|
2019-06-07 17:44:08 +08:00
|
|
|
*/
|
2020-08-29 15:46:24 +08:00
|
|
|
if (name_id != 0 && (meth_id = evp_method_id(name_id, operation_id)) == 0) {
|
2020-10-17 13:07:41 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, ERR_R_INTERNAL_ERROR);
|
2019-06-07 17:44:08 +08:00
|
|
|
return NULL;
|
2020-08-29 15:46:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we haven't found the name yet, chances are that the algorithm to
|
|
|
|
* be fetched is unsupported.
|
|
|
|
*/
|
|
|
|
if (name_id == 0)
|
|
|
|
unsupported = 1;
|
2019-06-07 17:44:08 +08:00
|
|
|
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
if (meth_id == 0
|
|
|
|
|| !ossl_method_store_cache_get(store, meth_id, properties, &method)) {
|
2019-02-09 00:01:56 +08:00
|
|
|
OSSL_METHOD_CONSTRUCT_METHOD mcm = {
|
2019-10-24 23:04:01 +08:00
|
|
|
alloc_tmp_evp_method_store,
|
|
|
|
dealloc_tmp_evp_method_store,
|
|
|
|
get_evp_method_from_store,
|
|
|
|
put_evp_method_in_store,
|
|
|
|
construct_evp_method,
|
|
|
|
destruct_evp_method
|
2019-02-09 00:01:56 +08:00
|
|
|
};
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st mcmdata;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
mcmdata.mcm = &mcm;
|
2019-05-04 18:56:32 +08:00
|
|
|
mcmdata.libctx = libctx;
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
mcmdata.operation_id = operation_id;
|
|
|
|
mcmdata.name_id = name_id;
|
2019-05-23 09:36:21 +08:00
|
|
|
mcmdata.names = name;
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
mcmdata.propquery = properties;
|
2021-03-16 21:14:43 +08:00
|
|
|
mcmdata.method_from_algorithm = new_method;
|
2019-07-02 20:57:36 +08:00
|
|
|
mcmdata.refcnt_up_method = up_ref_method;
|
2019-02-09 00:01:56 +08:00
|
|
|
mcmdata.destruct_method = free_method;
|
2021-03-03 01:15:32 +08:00
|
|
|
mcmdata.flag_construct_error_occurred = 0;
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
if ((method = ossl_method_construct(libctx, operation_id,
|
|
|
|
0 /* !force_cache */,
|
2019-06-28 21:29:34 +08:00
|
|
|
&mcm, &mcmdata)) != NULL) {
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
|
|
|
* If construction did create a method for us, we know that
|
2019-10-24 23:04:01 +08:00
|
|
|
* there is a correct name_id and meth_id, since those have
|
|
|
|
* already been calculated in get_evp_method_from_store() and
|
|
|
|
* put_evp_method_in_store() above.
|
2019-06-07 17:44:08 +08:00
|
|
|
*/
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
if (name_id == 0)
|
|
|
|
name_id = ossl_namemap_name2num(namemap, name);
|
2020-04-17 01:10:14 +08:00
|
|
|
meth_id = evp_method_id(name_id, operation_id);
|
2019-11-11 09:17:32 +08:00
|
|
|
ossl_method_store_cache_set(store, meth_id, properties, method,
|
|
|
|
up_ref_method, free_method);
|
2019-06-07 17:44:08 +08:00
|
|
|
}
|
2020-08-29 15:46:24 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we never were in the constructor, the algorithm to be fetched
|
|
|
|
* is unsupported.
|
|
|
|
*/
|
2021-03-03 01:15:32 +08:00
|
|
|
unsupported = !mcmdata.flag_construct_error_occurred;
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2020-08-29 15:46:24 +08:00
|
|
|
if (method == NULL) {
|
2020-10-17 13:07:41 +08:00
|
|
|
int code = unsupported ? ERR_R_UNSUPPORTED : ERR_R_FETCH_FAILED;
|
2019-04-05 16:46:18 +08:00
|
|
|
|
2020-08-29 15:46:24 +08:00
|
|
|
if (name == NULL)
|
|
|
|
name = ossl_namemap_num2name(namemap, name_id, 0);
|
|
|
|
ERR_raise_data(ERR_LIB_EVP, code,
|
|
|
|
"%s, Algorithm (%s : %d), Properties (%s)",
|
2020-10-17 13:07:41 +08:00
|
|
|
ossl_lib_ctx_get_descriptor(libctx),
|
2020-08-29 15:46:24 +08:00
|
|
|
name = NULL ? "<null>" : name, name_id,
|
|
|
|
properties == NULL ? "<null>" : properties);
|
|
|
|
}
|
|
|
|
|
|
|
|
return method;
|
2020-06-23 16:09:20 +08:00
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
void *evp_generic_fetch(OSSL_LIB_CTX *libctx, int operation_id,
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
const char *name, const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
2021-03-16 21:14:43 +08:00
|
|
|
const OSSL_ALGORITHM *algodef,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
2020-08-29 15:46:24 +08:00
|
|
|
return inner_evp_generic_fetch(libctx,
|
|
|
|
operation_id, 0, name, properties,
|
|
|
|
new_method, up_ref_method, free_method);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* evp_generic_fetch_by_number() is special, and only returns methods for
|
|
|
|
* already known names, i.e. it refuses to work if no name_id can be found
|
|
|
|
* (it's considered an internal programming error).
|
|
|
|
* This is meant to be used when one method needs to fetch an associated
|
|
|
|
* other method.
|
|
|
|
*/
|
2020-10-15 17:55:50 +08:00
|
|
|
void *evp_generic_fetch_by_number(OSSL_LIB_CTX *libctx, int operation_id,
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
int name_id, const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
2021-03-16 21:14:43 +08:00
|
|
|
const OSSL_ALGORITHM *algodef,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
2020-08-29 15:46:24 +08:00
|
|
|
return inner_evp_generic_fetch(libctx,
|
|
|
|
operation_id, name_id, NULL,
|
|
|
|
properties, new_method, up_ref_method,
|
|
|
|
free_method);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
}
|
|
|
|
|
2021-03-30 08:29:01 +08:00
|
|
|
int evp_method_store_flush(OSSL_LIB_CTX *libctx)
|
2020-08-09 16:06:52 +08:00
|
|
|
{
|
|
|
|
OSSL_METHOD_STORE *store = get_evp_method_store(libctx);
|
|
|
|
|
|
|
|
if (store != NULL)
|
2021-03-30 08:29:01 +08:00
|
|
|
return ossl_method_store_flush_cache(store, 1);
|
|
|
|
return 1;
|
2020-08-09 16:06:52 +08:00
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static int evp_set_parsed_default_properties(OSSL_LIB_CTX *libctx,
|
2020-08-01 00:29:21 +08:00
|
|
|
OSSL_PROPERTY_LIST *def_prop,
|
|
|
|
int loadconfig)
|
2019-04-05 16:46:18 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
OSSL_METHOD_STORE *store = get_evp_method_store(libctx);
|
2020-08-01 00:29:21 +08:00
|
|
|
OSSL_PROPERTY_LIST **plp = ossl_ctx_global_properties(libctx, loadconfig);
|
2020-06-12 08:34:46 +08:00
|
|
|
|
|
|
|
if (plp != NULL) {
|
|
|
|
ossl_property_free(*plp);
|
|
|
|
*plp = def_prop;
|
|
|
|
if (store != NULL)
|
2021-03-30 08:29:01 +08:00
|
|
|
return ossl_method_store_flush_cache(store, 0);
|
2020-06-12 08:34:46 +08:00
|
|
|
return 1;
|
|
|
|
}
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, ERR_R_INTERNAL_ERROR);
|
2019-04-05 16:46:18 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2019-07-13 12:53:44 +08:00
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
int evp_set_default_properties_int(OSSL_LIB_CTX *libctx, const char *propq,
|
2020-08-01 00:29:21 +08:00
|
|
|
int loadconfig)
|
2020-06-12 08:34:46 +08:00
|
|
|
{
|
|
|
|
OSSL_PROPERTY_LIST *pl = NULL;
|
|
|
|
|
2021-03-13 08:34:49 +08:00
|
|
|
if (propq != NULL && (pl = ossl_parse_query(libctx, propq, 1)) == NULL) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, EVP_R_DEFAULT_QUERY_PARSE_ERROR);
|
2020-06-12 08:34:46 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2020-08-01 00:29:21 +08:00
|
|
|
return evp_set_parsed_default_properties(libctx, pl, loadconfig);
|
2020-06-12 08:34:46 +08:00
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
int EVP_set_default_properties(OSSL_LIB_CTX *libctx, const char *propq)
|
2020-08-01 00:29:21 +08:00
|
|
|
{
|
|
|
|
return evp_set_default_properties_int(libctx, propq, 1);
|
|
|
|
}
|
2020-05-02 12:17:54 +08:00
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static int evp_default_properties_merge(OSSL_LIB_CTX *libctx, const char *propq)
|
2020-05-02 12:17:54 +08:00
|
|
|
{
|
2020-08-01 00:29:21 +08:00
|
|
|
OSSL_PROPERTY_LIST **plp = ossl_ctx_global_properties(libctx, 1);
|
2020-06-12 08:34:46 +08:00
|
|
|
OSSL_PROPERTY_LIST *pl1, *pl2;
|
|
|
|
|
|
|
|
if (propq == NULL)
|
|
|
|
return 1;
|
|
|
|
if (plp == NULL || *plp == NULL)
|
|
|
|
return EVP_set_default_properties(libctx, propq);
|
2021-03-13 08:34:49 +08:00
|
|
|
if ((pl1 = ossl_parse_query(libctx, propq, 1)) == NULL) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, EVP_R_DEFAULT_QUERY_PARSE_ERROR);
|
2020-06-12 08:34:46 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
pl2 = ossl_property_merge(pl1, *plp);
|
|
|
|
ossl_property_free(pl1);
|
|
|
|
if (pl2 == NULL) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_EVP, ERR_R_MALLOC_FAILURE);
|
2020-06-12 08:34:46 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2020-08-01 00:29:21 +08:00
|
|
|
return evp_set_parsed_default_properties(libctx, pl2, 0);
|
2020-05-02 12:17:54 +08:00
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
static int evp_default_property_is_enabled(OSSL_LIB_CTX *libctx,
|
2020-05-02 12:17:54 +08:00
|
|
|
const char *prop_name)
|
|
|
|
{
|
2020-08-01 00:29:21 +08:00
|
|
|
OSSL_PROPERTY_LIST **plp = ossl_ctx_global_properties(libctx, 1);
|
2020-05-02 12:17:54 +08:00
|
|
|
|
2020-06-12 08:34:46 +08:00
|
|
|
return plp != NULL && ossl_property_is_enabled(libctx, prop_name, *plp);
|
2020-05-02 12:17:54 +08:00
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
int EVP_default_properties_is_fips_enabled(OSSL_LIB_CTX *libctx)
|
2020-05-02 12:17:54 +08:00
|
|
|
{
|
|
|
|
return evp_default_property_is_enabled(libctx, "fips");
|
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
int EVP_default_properties_enable_fips(OSSL_LIB_CTX *libctx, int enable)
|
2020-05-02 12:17:54 +08:00
|
|
|
{
|
|
|
|
const char *query = (enable != 0) ? "fips=yes" : "-fips";
|
|
|
|
|
|
|
|
return evp_default_properties_merge(libctx, query);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-07-13 12:53:44 +08:00
|
|
|
struct do_all_data_st {
|
|
|
|
void (*user_fn)(void *method, void *arg);
|
|
|
|
void *user_arg;
|
2021-03-16 21:14:43 +08:00
|
|
|
void *(*new_method)(const int name_id, const OSSL_ALGORITHM *algodef,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov);
|
2019-07-13 12:53:44 +08:00
|
|
|
void (*free_method)(void *);
|
|
|
|
};
|
|
|
|
|
|
|
|
static void do_one(OSSL_PROVIDER *provider, const OSSL_ALGORITHM *algo,
|
|
|
|
int no_store, void *vdata)
|
|
|
|
{
|
|
|
|
struct do_all_data_st *data = vdata;
|
2020-10-15 17:55:50 +08:00
|
|
|
OSSL_LIB_CTX *libctx = ossl_provider_libctx(provider);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
2019-11-09 07:18:05 +08:00
|
|
|
int name_id = ossl_namemap_add_names(namemap, 0, algo->algorithm_names,
|
|
|
|
NAME_SEPARATOR);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
void *method = NULL;
|
|
|
|
|
|
|
|
if (name_id != 0)
|
2021-03-16 21:14:43 +08:00
|
|
|
method = data->new_method(name_id, algo, provider);
|
2019-07-13 12:53:44 +08:00
|
|
|
|
|
|
|
if (method != NULL) {
|
|
|
|
data->user_fn(method, data->user_arg);
|
|
|
|
data->free_method(method);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-15 17:55:50 +08:00
|
|
|
void evp_generic_do_all(OSSL_LIB_CTX *libctx, int operation_id,
|
2019-07-13 12:53:44 +08:00
|
|
|
void (*user_fn)(void *method, void *arg),
|
|
|
|
void *user_arg,
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
void *(*new_method)(int name_id,
|
2021-03-16 21:14:43 +08:00
|
|
|
const OSSL_ALGORITHM *algodef,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
2019-07-13 12:53:44 +08:00
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
|
|
|
struct do_all_data_st data;
|
|
|
|
|
|
|
|
data.new_method = new_method;
|
|
|
|
data.free_method = free_method;
|
|
|
|
data.user_fn = user_fn;
|
|
|
|
data.user_arg = user_arg;
|
2020-05-15 21:56:05 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* No pre- or post-condition for this call, as this only creates methods
|
|
|
|
* temporarly and then promptly destroys them.
|
|
|
|
*/
|
|
|
|
ossl_algorithm_do_all(libctx, operation_id, NULL, NULL, do_one, NULL,
|
|
|
|
&data);
|
2019-07-13 12:53:44 +08:00
|
|
|
}
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
|
2020-02-12 21:28:50 +08:00
|
|
|
const char *evp_first_name(const OSSL_PROVIDER *prov, int name_id)
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
{
|
2020-10-15 17:55:50 +08:00
|
|
|
OSSL_LIB_CTX *libctx = ossl_provider_libctx(prov);
|
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)
2019-09-14 22:22:19 +08:00
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
return ossl_namemap_num2name(namemap, name_id, 0);
|
|
|
|
}
|
2019-09-14 22:35:08 +08:00
|
|
|
|
2020-01-15 08:04:37 +08:00
|
|
|
int evp_is_a(OSSL_PROVIDER *prov, int number,
|
|
|
|
const char *legacy_name, const char *name)
|
2019-09-14 22:35:08 +08:00
|
|
|
{
|
2020-01-15 08:04:37 +08:00
|
|
|
/*
|
|
|
|
* For a |prov| that is NULL, the library context will be NULL
|
|
|
|
*/
|
2020-10-15 17:55:50 +08:00
|
|
|
OSSL_LIB_CTX *libctx = ossl_provider_libctx(prov);
|
2019-09-14 22:35:08 +08:00
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
2020-01-15 08:04:37 +08:00
|
|
|
if (prov == NULL)
|
|
|
|
number = ossl_namemap_name2num(namemap, legacy_name);
|
2019-09-14 22:35:08 +08:00
|
|
|
return ossl_namemap_name2num(namemap, name) == number;
|
|
|
|
}
|
2019-09-22 02:57:51 +08:00
|
|
|
|
2021-02-20 01:03:43 +08:00
|
|
|
int evp_names_do_all(OSSL_PROVIDER *prov, int number,
|
|
|
|
void (*fn)(const char *name, void *data),
|
|
|
|
void *data)
|
2019-09-22 02:57:51 +08:00
|
|
|
{
|
2020-10-15 17:55:50 +08:00
|
|
|
OSSL_LIB_CTX *libctx = ossl_provider_libctx(prov);
|
2019-09-22 02:57:51 +08:00
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
2021-02-20 01:03:43 +08:00
|
|
|
return ossl_namemap_doall_names(namemap, number, fn, data);
|
2019-09-22 02:57:51 +08:00
|
|
|
}
|