2019-02-09 00:01:56 +08:00
|
|
|
/*
|
|
|
|
* Copyright 2019 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
*
|
|
|
|
* 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>
|
|
|
|
#include <openssl/ossl_typ.h>
|
|
|
|
#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"
|
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
|
|
|
|
|
|
|
static void default_method_store_free(void *vstore)
|
|
|
|
{
|
|
|
|
ossl_method_store_free(vstore);
|
|
|
|
}
|
|
|
|
|
2019-05-01 18:02:43 +08:00
|
|
|
static void *default_method_store_new(OPENSSL_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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static const OPENSSL_CTX_METHOD default_method_store_method = {
|
|
|
|
default_method_store_new,
|
|
|
|
default_method_store_free,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Data to be passed through ossl_method_construct() */
|
|
|
|
struct method_data_st {
|
2019-05-04 18:56:32 +08:00
|
|
|
OPENSSL_CTX *libctx;
|
2019-02-09 00:01:56 +08:00
|
|
|
OSSL_METHOD_CONSTRUCT_METHOD *mcm;
|
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 operation_id; /* For get_method_from_store() */
|
|
|
|
int name_id; /* For get_method_from_store() */
|
|
|
|
const char *name; /* For get_method_from_store() */
|
|
|
|
const char *propquery; /* For get_method_from_store() */
|
|
|
|
void *(*method_from_dispatch)(int name_id, const OSSL_DISPATCH *,
|
2019-08-23 20:03:28 +08:00
|
|
|
OSSL_PROVIDER *, void *);
|
|
|
|
void *method_data;
|
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()
|
|
|
|
*/
|
2019-05-01 18:02:43 +08:00
|
|
|
static void *alloc_tmp_method_store(OPENSSL_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
|
|
|
}
|
|
|
|
|
|
|
|
static void dealloc_tmp_method_store(void *store)
|
|
|
|
{
|
|
|
|
if (store != NULL)
|
|
|
|
ossl_method_store_free(store);
|
|
|
|
}
|
|
|
|
|
2019-04-05 16:46:18 +08:00
|
|
|
static OSSL_METHOD_STORE *get_default_method_store(OPENSSL_CTX *libctx)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-05-01 18:02:43 +08:00
|
|
|
return openssl_ctx_get_data(libctx, OPENSSL_CTX_DEFAULT_METHOD_STORE_INDEX,
|
|
|
|
&default_method_store_method);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
|
|
|
* To identity the method in the method store, we mix the name identity
|
|
|
|
* with the operation identity, with the assumption that we don't have
|
|
|
|
* more than 2^24 names or more than 2^8 operation types.
|
|
|
|
*
|
|
|
|
* The resulting identity is a 32-bit integer, composed like this:
|
|
|
|
*
|
|
|
|
* +---------24 bits--------+-8 bits-+
|
|
|
|
* | name identity | op 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
|
|
|
static uint32_t method_id(unsigned int operation_id, int name_id)
|
2019-06-07 17:44:08 +08:00
|
|
|
{
|
|
|
|
if (!ossl_assert(name_id < (1 << 24) || operation_id < (1 << 8))
|
|
|
|
|| !ossl_assert(name_id > 0 && operation_id > 0))
|
|
|
|
return 0;
|
|
|
|
return ((name_id << 8) & 0xFFFFFF00) | (operation_id & 0x000000FF);
|
|
|
|
}
|
|
|
|
|
2019-02-09 00:01:56 +08:00
|
|
|
static void *get_method_from_store(OPENSSL_CTX *libctx, void *store,
|
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 *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
struct method_data_st *methdata = data;
|
|
|
|
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
|
|
|
/*
|
|
|
|
* get_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.
|
|
|
|
*/
|
|
|
|
if ((name_id = methdata->name_id) == 0) {
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
if (namemap == 0)
|
|
|
|
return NULL;
|
|
|
|
name_id = ossl_namemap_name2num(namemap, methdata->name);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (name_id == 0
|
|
|
|
|| (meth_id = method_id(methdata->operation_id, name_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
|
|
|
|
&& (store = get_default_method_store(libctx)) == NULL)
|
2019-05-05 14:42:21 +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
|
|
|
(void)ossl_method_store_fetch(store, meth_id, methdata->propquery,
|
|
|
|
&method);
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
if (method != NULL
|
|
|
|
&& !methdata->refcnt_up_method(method)) {
|
|
|
|
method = NULL;
|
|
|
|
}
|
|
|
|
return method;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int put_method_in_store(OPENSSL_CTX *libctx, void *store,
|
2019-08-21 16:08:44 +08:00
|
|
|
void *method, const OSSL_PROVIDER *prov,
|
|
|
|
int operation_id, const char *name,
|
|
|
|
const char *propdef, void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
struct 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-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
|
|
|
/*
|
|
|
|
* put_method_in_store() is only called with a method that was
|
|
|
|
* successfully created by construct_method() below, which means
|
|
|
|
* the name should already be stored in the namemap, so just use it.
|
|
|
|
*/
|
|
|
|
if ((namemap = ossl_namemap_stored(libctx)) == NULL
|
|
|
|
|| (name_id = ossl_namemap_name2num(namemap, name)) == 0
|
|
|
|
|| (meth_id = method_id(operation_id, name_id)) == 0)
|
2019-03-21 01:51:29 +08:00
|
|
|
return 0;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
if (store == NULL
|
|
|
|
&& (store = get_default_method_store(libctx)) == NULL)
|
|
|
|
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-05-05 14:42:21 +08:00
|
|
|
static void *construct_method(const char *name, const OSSL_DISPATCH *fns,
|
|
|
|
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
|
|
|
/*
|
|
|
|
* This function is only called if get_method_from_store() returned
|
|
|
|
* 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
|
|
|
|
* know that ossl_namemap_add() will return its corresponding number.
|
|
|
|
*
|
|
|
|
* TODO(3.0): If this function gets an array of names instead of just
|
|
|
|
* one, we need to check through all the names to see if at least one
|
|
|
|
* of them has an associated number, and use that. If several names
|
|
|
|
* have associated numbers that differ from each other, it's an error.
|
|
|
|
*/
|
2019-02-09 00:01:56 +08:00
|
|
|
struct method_data_st *methdata = data;
|
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
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
int name_id = ossl_namemap_add(namemap, 0, name);
|
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
|
|
|
return methdata->method_from_dispatch(name_id, fns, prov,
|
2019-08-23 20:03:28 +08:00
|
|
|
methdata->method_data);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void destruct_method(void *method, void *data)
|
|
|
|
{
|
|
|
|
struct method_data_st *methdata = data;
|
|
|
|
|
|
|
|
methdata->destruct_method(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
|
|
|
static void *inner_generic_fetch(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
int name_id, const char *name,
|
|
|
|
const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
|
|
|
OSSL_PROVIDER *prov,
|
|
|
|
void *method_data),
|
|
|
|
void *method_data,
|
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-04-18 18:23:21 +08:00
|
|
|
OSSL_METHOD_STORE *store = get_default_method_store(libctx);
|
2019-05-04 18:56:32 +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;
|
|
|
|
|
2019-05-04 18:56:32 +08:00
|
|
|
if (store == NULL || namemap == NULL)
|
2019-04-18 18:23:21 +08:00
|
|
|
return NULL;
|
|
|
|
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
|
|
|
* If there's ever an operation_id == 0 passed, we have an internal
|
|
|
|
* programming error.
|
|
|
|
*/
|
|
|
|
if (!ossl_assert(operation_id > 0))
|
|
|
|
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 we have been passed neither a name_id or a name, we have an
|
|
|
|
* internal programming error.
|
|
|
|
*/
|
|
|
|
if (!ossl_assert(name_id != 0 || name != NULL))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have a name id, calculate a method id with method_id().
|
|
|
|
*
|
2019-06-07 17:44:08 +08:00
|
|
|
* 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.
|
|
|
|
*/
|
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 && (meth_id = method_id(operation_id, name_id)) == 0)
|
2019-06-07 17:44:08 +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 (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 = {
|
|
|
|
alloc_tmp_method_store,
|
|
|
|
dealloc_tmp_method_store,
|
|
|
|
get_method_from_store,
|
|
|
|
put_method_in_store,
|
|
|
|
construct_method,
|
|
|
|
destruct_method
|
|
|
|
};
|
|
|
|
struct method_data_st mcmdata;
|
|
|
|
|
|
|
|
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-04-11 18:27:59 +08:00
|
|
|
mcmdata.name = 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;
|
2019-02-09 00:01:56 +08:00
|
|
|
mcmdata.method_from_dispatch = new_method;
|
|
|
|
mcmdata.destruct_method = free_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;
|
2019-08-23 20:03:28 +08:00
|
|
|
mcmdata.method_data = method_data;
|
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
|
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
|
|
|
* there is a correct name_id and methodid, since those have
|
2019-06-07 17:44:08 +08:00
|
|
|
* already been calculated in get_method_from_store() and
|
|
|
|
* put_method_in_store() above.
|
|
|
|
*/
|
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);
|
|
|
|
meth_id = method_id(operation_id, name_id);
|
|
|
|
ossl_method_store_cache_set(store, meth_id, properties, method);
|
2019-06-07 17:44:08 +08:00
|
|
|
}
|
2019-04-18 18:23:21 +08:00
|
|
|
} else {
|
2019-07-02 20:57:36 +08:00
|
|
|
up_ref_method(method);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return method;
|
|
|
|
}
|
2019-04-05 16:46:18 +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
|
|
|
void *evp_generic_fetch(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
const char *name, const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
|
|
|
OSSL_PROVIDER *prov,
|
|
|
|
void *method_data),
|
|
|
|
void *method_data,
|
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
|
|
|
return inner_generic_fetch(libctx,
|
|
|
|
operation_id, 0, name, properties,
|
|
|
|
new_method, method_data,
|
|
|
|
up_ref_method, free_method);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
void *evp_generic_fetch_by_number(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
int name_id, const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
|
|
|
OSSL_PROVIDER *prov,
|
|
|
|
void *method_data),
|
|
|
|
void *method_data,
|
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
|
|
|
return inner_generic_fetch(libctx,
|
|
|
|
operation_id, name_id, NULL, properties,
|
|
|
|
new_method, method_data,
|
|
|
|
up_ref_method, free_method);
|
|
|
|
}
|
|
|
|
|
2019-04-05 16:46:18 +08:00
|
|
|
int EVP_set_default_properties(OPENSSL_CTX *libctx, const char *propq)
|
|
|
|
{
|
|
|
|
OSSL_METHOD_STORE *store = get_default_method_store(libctx);
|
|
|
|
|
|
|
|
if (store != NULL)
|
|
|
|
return ossl_method_store_set_global_properties(store, propq);
|
|
|
|
EVPerr(EVP_F_EVP_SET_DEFAULT_PROPERTIES, ERR_R_INTERNAL_ERROR);
|
|
|
|
return 0;
|
|
|
|
}
|
2019-07-13 12:53:44 +08:00
|
|
|
|
|
|
|
struct do_all_data_st {
|
|
|
|
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)(const int name_id, const OSSL_DISPATCH *fns,
|
2019-08-23 20:03:28 +08:00
|
|
|
OSSL_PROVIDER *prov, void *method_data);
|
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;
|
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
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(provider);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
int name_id = ossl_namemap_add(namemap, 0, algo->algorithm_name);
|
|
|
|
void *method = NULL;
|
|
|
|
|
|
|
|
if (name_id != 0)
|
|
|
|
method = data->new_method(name_id, algo->implementation, provider,
|
|
|
|
NULL);
|
2019-07-13 12:53:44 +08:00
|
|
|
|
|
|
|
if (method != NULL) {
|
|
|
|
data->user_fn(method, data->user_arg);
|
|
|
|
data->free_method(method);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void evp_generic_do_all(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
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,
|
2019-07-13 12:53:44 +08:00
|
|
|
const OSSL_DISPATCH *fns,
|
2019-08-23 20:03:28 +08:00
|
|
|
OSSL_PROVIDER *prov,
|
|
|
|
void *method_data),
|
|
|
|
void *method_data,
|
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;
|
2019-08-23 20:03:28 +08:00
|
|
|
ossl_algorithm_do_all(libctx, operation_id, method_data, do_one, &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
|
|
|
|
|
|
|
const char *evp_first_name(OSSL_PROVIDER *prov, int name_id)
|
|
|
|
{
|
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
return ossl_namemap_num2name(namemap, name_id, 0);
|
|
|
|
}
|
2019-09-14 22:35:08 +08:00
|
|
|
|
|
|
|
int evp_is_a(OSSL_PROVIDER *prov, int number, const char *name)
|
|
|
|
{
|
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
return ossl_namemap_name2num(namemap, name) == number;
|
|
|
|
}
|
2019-09-22 02:57:51 +08:00
|
|
|
|
|
|
|
void evp_doall_names(OSSL_PROVIDER *prov, int number,
|
|
|
|
void (*fn)(const char *name, void *data),
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
ossl_namemap_doall_names(namemap, number, fn, data);
|
|
|
|
}
|