2000-10-26 21:07:28 +00:00
|
|
|
/* openssl/engine.h */
|
|
|
|
/* Written by Geoff Thorpe (geoff@geoffthorpe.net) for the OpenSSL
|
|
|
|
* project 2000.
|
|
|
|
*/
|
|
|
|
/* ====================================================================
|
2001-09-14 18:31:57 +00:00
|
|
|
* Copyright (c) 1999-2001 The OpenSSL Project. All rights reserved.
|
2000-10-26 21:07:28 +00:00
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
*
|
|
|
|
* 3. All advertising materials mentioning features or use of this
|
|
|
|
* software must display the following acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
|
|
|
|
*
|
|
|
|
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
|
|
|
|
* endorse or promote products derived from this software without
|
|
|
|
* prior written permission. For written permission, please contact
|
|
|
|
* licensing@OpenSSL.org.
|
|
|
|
*
|
|
|
|
* 5. Products derived from this software may not be called "OpenSSL"
|
|
|
|
* nor may "OpenSSL" appear in their names without prior written
|
|
|
|
* permission of the OpenSSL Project.
|
|
|
|
*
|
|
|
|
* 6. Redistributions of any form whatsoever must retain the following
|
|
|
|
* acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
|
|
|
|
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
|
|
|
|
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
* ====================================================================
|
|
|
|
*
|
|
|
|
* This product includes cryptographic software written by Eric Young
|
|
|
|
* (eay@cryptsoft.com). This product includes software written by Tim
|
|
|
|
* Hudson (tjh@cryptsoft.com).
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef HEADER_ENGINE_H
|
|
|
|
#define HEADER_ENGINE_H
|
|
|
|
|
2001-10-04 07:32:46 +00:00
|
|
|
#include <openssl/ossl_typ.h>
|
2000-10-26 21:07:28 +00:00
|
|
|
#include <openssl/bn.h>
|
2001-04-26 15:45:12 +00:00
|
|
|
#ifndef OPENSSL_NO_RSA
|
2000-10-26 21:07:28 +00:00
|
|
|
#include <openssl/rsa.h>
|
2001-04-26 15:45:12 +00:00
|
|
|
#endif
|
|
|
|
#ifndef OPENSSL_NO_DSA
|
2000-10-26 21:07:28 +00:00
|
|
|
#include <openssl/dsa.h>
|
2001-04-26 15:45:12 +00:00
|
|
|
#endif
|
|
|
|
#ifndef OPENSSL_NO_DH
|
2000-10-26 21:07:28 +00:00
|
|
|
#include <openssl/dh.h>
|
2001-04-26 15:45:12 +00:00
|
|
|
#endif
|
2002-02-13 18:21:51 +00:00
|
|
|
#ifndef OPENSSL_NO_ECDSA
|
|
|
|
#include <openssl/ecdsa.h>
|
|
|
|
#endif
|
2000-10-26 21:07:28 +00:00
|
|
|
#include <openssl/rand.h>
|
2001-06-19 16:12:18 +00:00
|
|
|
#include <openssl/ui.h>
|
2000-10-26 21:07:28 +00:00
|
|
|
#include <openssl/symhacks.h>
|
2001-09-03 19:15:29 +00:00
|
|
|
#include <openssl/err.h>
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2001-04-26 15:45:12 +00:00
|
|
|
/* Fixups for missing algorithms */
|
|
|
|
#ifdef OPENSSL_NO_RSA
|
|
|
|
typedef void RSA_METHOD;
|
|
|
|
#endif
|
|
|
|
#ifdef OPENSSL_NO_DSA
|
|
|
|
typedef void DSA_METHOD;
|
|
|
|
#endif
|
|
|
|
#ifdef OPENSSL_NO_DH
|
|
|
|
typedef void DH_METHOD;
|
|
|
|
#endif
|
2002-02-13 18:21:51 +00:00
|
|
|
#ifdef OPENSS_NO_ECDSA
|
|
|
|
typedef void ECDSA_METHOD;
|
|
|
|
#endif
|
2001-04-26 15:45:12 +00:00
|
|
|
|
2000-10-26 21:07:28 +00:00
|
|
|
/* These flags are used to control combinations of algorithm (methods)
|
|
|
|
* by bitwise "OR"ing. */
|
|
|
|
#define ENGINE_METHOD_RSA (unsigned int)0x0001
|
|
|
|
#define ENGINE_METHOD_DSA (unsigned int)0x0002
|
|
|
|
#define ENGINE_METHOD_DH (unsigned int)0x0004
|
|
|
|
#define ENGINE_METHOD_RAND (unsigned int)0x0008
|
2002-02-13 18:21:51 +00:00
|
|
|
#define ENGINE_METHOD_ECDSA (unsigned int)0x000F
|
2001-09-25 21:28:40 +00:00
|
|
|
#define ENGINE_METHOD_CIPHERS (unsigned int)0x0040
|
|
|
|
#define ENGINE_METHOD_DIGESTS (unsigned int)0x0080
|
2000-10-26 21:07:28 +00:00
|
|
|
/* Obvious all-or-nothing cases. */
|
|
|
|
#define ENGINE_METHOD_ALL (unsigned int)0xFFFF
|
|
|
|
#define ENGINE_METHOD_NONE (unsigned int)0x0000
|
|
|
|
|
2001-09-25 20:00:51 +00:00
|
|
|
/* This(ese) flag(s) controls behaviour of the ENGINE_TABLE mechanism used
|
|
|
|
* internally to control registration of ENGINE implementations, and can be set
|
|
|
|
* by ENGINE_set_table_flags(). The "NOINIT" flag prevents attempts to
|
|
|
|
* initialise registered ENGINEs if they are not already initialised. */
|
|
|
|
#define ENGINE_TABLE_FLAG_NOINIT (unsigned int)0x0001
|
|
|
|
|
2001-04-18 03:03:16 +00:00
|
|
|
/* ENGINE flags that can be set by ENGINE_set_flags(). */
|
|
|
|
/* #define ENGINE_FLAGS_MALLOCED 0x0001 */ /* Not used */
|
|
|
|
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
/* This flag is for ENGINEs that wish to handle the various 'CMD'-related
|
|
|
|
* control commands on their own. Without this flag, ENGINE_ctrl() handles these
|
|
|
|
* control commands on behalf of the ENGINE using their "cmd_defns" data. */
|
|
|
|
#define ENGINE_FLAGS_MANUAL_CMD_CTRL (int)0x0002
|
|
|
|
|
This adds 2 things to the ENGINE code.
* "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself
that allows an ENGINE to store its own information there rather than in
global variables. It follows the declarations and implementations used
in RSA code, for better or worse. However there's a problem when storing
state with ENGINEs because, unlike related structure types in OpenSSL,
there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE
is, it has method pointers as its structure elements ... which leads
to;
* ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a
reference to an "implementation" (eg. to get to a hardware device), but
should also be able to maintain state, then this flag can be set by the
ENGINE implementation. The result is that any call to ENGINE_by_id()
will not result in the existing ENGINE being returned (with its
structural reference count incremented) but instead a new copy of the
ENGINE will be returned that can maintain its own state independantly of
any other copies returned in the past or future. Eg. key-generation
might involve a series of ENGINE-specific control commands to set
algorithms, sizes, module-keys, ids, ACLs, etc. A final command could
generate the key. An ENGINE doing this would *have* to declare
ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be
maintained "per-handle" and unaffected by other code having a reference
to the same ENGINE structure.
2001-04-26 19:35:44 +00:00
|
|
|
/* This flag is for ENGINEs who return new duplicate structures when found via
|
|
|
|
* "ENGINE_by_id()". When an ENGINE must store state (eg. if ENGINE_ctrl()
|
|
|
|
* commands are called in sequence as part of some stateful process like
|
|
|
|
* key-generation setup and execution), it can set this flag - then each attempt
|
|
|
|
* to obtain the ENGINE will result in it being copied into a new structure.
|
|
|
|
* Normally, ENGINEs don't declare this flag so ENGINE_by_id() just increments
|
|
|
|
* the existing ENGINE's structural reference count. */
|
|
|
|
#define ENGINE_FLAGS_BY_ID_COPY (int)0x0004
|
|
|
|
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
/* ENGINEs can support their own command types, and these flags are used in
|
|
|
|
* ENGINE_CTRL_GET_CMD_FLAGS to indicate to the caller what kind of input each
|
|
|
|
* command expects. Currently only numeric and string input is supported. If a
|
|
|
|
* control command supports none of the _NUMERIC, _STRING, or _NO_INPUT options,
|
|
|
|
* then it is regarded as an "internal" control command - and not for use in
|
|
|
|
* config setting situations. As such, they're not available to the
|
|
|
|
* ENGINE_ctrl_cmd_string() function, only raw ENGINE_ctrl() access. Changes to
|
|
|
|
* this list of 'command types' should be reflected carefully in
|
|
|
|
* ENGINE_cmd_is_executable() and ENGINE_ctrl_cmd_string(). */
|
|
|
|
|
|
|
|
/* accepts a 'long' input value (3rd parameter to ENGINE_ctrl) */
|
|
|
|
#define ENGINE_CMD_FLAG_NUMERIC (unsigned int)0x0001
|
|
|
|
/* accepts string input (cast from 'void*' to 'const char *', 4th parameter to
|
|
|
|
* ENGINE_ctrl) */
|
|
|
|
#define ENGINE_CMD_FLAG_STRING (unsigned int)0x0002
|
|
|
|
/* Indicates that the control command takes *no* input. Ie. the control command
|
|
|
|
* is unparameterised. */
|
|
|
|
#define ENGINE_CMD_FLAG_NO_INPUT (unsigned int)0x0004
|
2001-06-19 16:12:18 +00:00
|
|
|
/* Indicates that the control command is internal. This control command won't
|
|
|
|
* be shown in any output, and is only usable through the ENGINE_ctrl_cmd()
|
|
|
|
* function. */
|
|
|
|
#define ENGINE_CMD_FLAG_INTERNAL (unsigned int)0x0008
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
|
|
|
|
/* NB: These 3 control commands are deprecated and should not be used. ENGINEs
|
|
|
|
* relying on these commands should compile conditional support for
|
|
|
|
* compatibility (eg. if these symbols are defined) but should also migrate the
|
|
|
|
* same functionality to their own ENGINE-specific control functions that can be
|
|
|
|
* "discovered" by calling applications. The fact these control commands
|
|
|
|
* wouldn't be "executable" (ie. usable by text-based config) doesn't change the
|
|
|
|
* fact that application code can find and use them without requiring per-ENGINE
|
|
|
|
* hacking. */
|
|
|
|
|
2000-10-26 21:07:28 +00:00
|
|
|
/* These flags are used to tell the ctrl function what should be done.
|
|
|
|
* All command numbers are shared between all engines, even if some don't
|
|
|
|
* make sense to some engines. In such a case, they do nothing but return
|
|
|
|
* the error ENGINE_R_CTRL_COMMAND_NOT_IMPLEMENTED. */
|
|
|
|
#define ENGINE_CTRL_SET_LOGSTREAM 1
|
|
|
|
#define ENGINE_CTRL_SET_PASSWORD_CALLBACK 2
|
Many applications that use OpenSSL with ENGINE support might face a
situation where they've initialised the ENGINE, loaded keys (which are then
linked to that ENGINE), and performed other checks (such as verifying
certificate chains etc). At that point, if the application goes
multi-threaded or multi-process it creates problems for any ENGINE
implementations that are either not thread/process safe or that perform
optimally when they do not have to perform locking and other contention
management tasks at "run-time".
This defines a new ENGINE_ctrl() command that can be supported by engines
at their discretion. If ENGINE_ctrl(..., ENGINE_CTRL_HUP,...) returns an
error then the caller should check if the *_R_COMMAND_NOT_IMPLEMENTED error
reason was set - it may just be that the engine doesn't support or need the
HUP command, or it could be that the attempted reinitialisation failed. A
crude alternative is to ignore the return value from ENGINE_ctrl() (and
clear any errors with ERR_clear_error()) and perform a test operation
immediately after the "HUP". Very crude indeed.
ENGINEs can support this command to close and reopen connections, files,
handles, or whatever as an alternative to run-time locking when such things
would otherwise be needed. In such a case, it's advisable for the engine
implementations to support locking by default but disable it after the
arrival of a HUP command, or any other indication by the application that
locking is not required. NB: This command exists to allow an ENGINE to
reinitialise without the ENGINE's functional reference count having to sink
down to zero and back up - which is what is normally required for the
finish() and init() handlers to get invoked. It would also be a bad idea
for engine_lib to catch this command itself and interpret it by calling the
engine's init() and finish() handlers directly, because reinitialisation
may need special handling on a case-by-case basis that is distinct from a
finish/init pair - eg. calling a finish() handler may invalidate the state
stored inside individual keys that have already loaded for this engine.
2000-11-16 00:15:50 +00:00
|
|
|
#define ENGINE_CTRL_HUP 3 /* Close and reinitialise any
|
|
|
|
handles/connections etc. */
|
2001-06-19 16:12:18 +00:00
|
|
|
#define ENGINE_CTRL_SET_USER_INTERFACE 4 /* Alternative to callback */
|
|
|
|
#define ENGINE_CTRL_SET_CALLBACK_DATA 5 /* User-specific data, used
|
|
|
|
when calling the password
|
|
|
|
callback and the user
|
|
|
|
interface */
|
Many applications that use OpenSSL with ENGINE support might face a
situation where they've initialised the ENGINE, loaded keys (which are then
linked to that ENGINE), and performed other checks (such as verifying
certificate chains etc). At that point, if the application goes
multi-threaded or multi-process it creates problems for any ENGINE
implementations that are either not thread/process safe or that perform
optimally when they do not have to perform locking and other contention
management tasks at "run-time".
This defines a new ENGINE_ctrl() command that can be supported by engines
at their discretion. If ENGINE_ctrl(..., ENGINE_CTRL_HUP,...) returns an
error then the caller should check if the *_R_COMMAND_NOT_IMPLEMENTED error
reason was set - it may just be that the engine doesn't support or need the
HUP command, or it could be that the attempted reinitialisation failed. A
crude alternative is to ignore the return value from ENGINE_ctrl() (and
clear any errors with ERR_clear_error()) and perform a test operation
immediately after the "HUP". Very crude indeed.
ENGINEs can support this command to close and reopen connections, files,
handles, or whatever as an alternative to run-time locking when such things
would otherwise be needed. In such a case, it's advisable for the engine
implementations to support locking by default but disable it after the
arrival of a HUP command, or any other indication by the application that
locking is not required. NB: This command exists to allow an ENGINE to
reinitialise without the ENGINE's functional reference count having to sink
down to zero and back up - which is what is normally required for the
finish() and init() handlers to get invoked. It would also be a bad idea
for engine_lib to catch this command itself and interpret it by calling the
engine's init() and finish() handlers directly, because reinitialisation
may need special handling on a case-by-case basis that is distinct from a
finish/init pair - eg. calling a finish() handler may invalidate the state
stored inside individual keys that have already loaded for this engine.
2000-11-16 00:15:50 +00:00
|
|
|
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
/* These control commands allow an application to deal with an arbitrary engine
|
|
|
|
* in a dynamic way. Warn: Negative return values indicate errors FOR THESE
|
|
|
|
* COMMANDS because zero is used to indicate 'end-of-list'. Other commands,
|
|
|
|
* including ENGINE-specific command types, return zero for an error.
|
|
|
|
*
|
|
|
|
* An ENGINE can choose to implement these ctrl functions, and can internally
|
|
|
|
* manage things however it chooses - it does so by setting the
|
|
|
|
* ENGINE_FLAGS_MANUAL_CMD_CTRL flag (using ENGINE_set_flags()). Otherwise the
|
|
|
|
* ENGINE_ctrl() code handles this on the ENGINE's behalf using the cmd_defns
|
|
|
|
* data (set using ENGINE_set_cmd_defns()). This means an ENGINE's ctrl()
|
|
|
|
* handler need only implement its own commands - the above "meta" commands will
|
|
|
|
* be taken care of. */
|
|
|
|
|
|
|
|
/* Returns non-zero if the supplied ENGINE has a ctrl() handler. If "not", then
|
|
|
|
* all the remaining control commands will return failure, so it is worth
|
|
|
|
* checking this first if the caller is trying to "discover" the engine's
|
|
|
|
* capabilities and doesn't want errors generated unnecessarily. */
|
|
|
|
#define ENGINE_CTRL_HAS_CTRL_FUNCTION 10
|
|
|
|
/* Returns a positive command number for the first command supported by the
|
|
|
|
* engine. Returns zero if no ctrl commands are supported. */
|
|
|
|
#define ENGINE_CTRL_GET_FIRST_CMD_TYPE 11
|
|
|
|
/* The 'long' argument specifies a command implemented by the engine, and the
|
|
|
|
* return value is the next command supported, or zero if there are no more. */
|
|
|
|
#define ENGINE_CTRL_GET_NEXT_CMD_TYPE 12
|
|
|
|
/* The 'void*' argument is a command name (cast from 'const char *'), and the
|
|
|
|
* return value is the command that corresponds to it. */
|
|
|
|
#define ENGINE_CTRL_GET_CMD_FROM_NAME 13
|
|
|
|
/* The next two allow a command to be converted into its corresponding string
|
|
|
|
* form. In each case, the 'long' argument supplies the command. In the NAME_LEN
|
|
|
|
* case, the return value is the length of the command name (not counting a
|
|
|
|
* trailing EOL). In the NAME case, the 'void*' argument must be a string buffer
|
|
|
|
* large enough, and it will be populated with the name of the command (WITH a
|
|
|
|
* trailing EOL). */
|
|
|
|
#define ENGINE_CTRL_GET_NAME_LEN_FROM_CMD 14
|
|
|
|
#define ENGINE_CTRL_GET_NAME_FROM_CMD 15
|
|
|
|
/* The next two are similar but give a "short description" of a command. */
|
|
|
|
#define ENGINE_CTRL_GET_DESC_LEN_FROM_CMD 16
|
|
|
|
#define ENGINE_CTRL_GET_DESC_FROM_CMD 17
|
|
|
|
/* With this command, the return value is the OR'd combination of
|
|
|
|
* ENGINE_CMD_FLAG_*** values that indicate what kind of input a given
|
|
|
|
* engine-specific ctrl command expects. */
|
|
|
|
#define ENGINE_CTRL_GET_CMD_FLAGS 18
|
|
|
|
|
|
|
|
/* ENGINE implementations should start the numbering of their own control
|
|
|
|
* commands from this value. (ie. ENGINE_CMD_BASE, ENGINE_CMD_BASE + 1, etc). */
|
|
|
|
#define ENGINE_CMD_BASE 200
|
|
|
|
|
|
|
|
/* NB: These 2 nCipher "chil" control commands are deprecated, and their
|
|
|
|
* functionality is now available through ENGINE-specific control commands
|
|
|
|
* (exposed through the above-mentioned 'CMD'-handling). Code using these 2
|
|
|
|
* commands should be migrated to the more general command handling before these
|
|
|
|
* are removed. */
|
|
|
|
|
2000-10-26 21:07:28 +00:00
|
|
|
/* Flags specific to the nCipher "chil" engine */
|
|
|
|
#define ENGINE_CTRL_CHIL_SET_FORKCHECK 100
|
|
|
|
/* Depending on the value of the (long)i argument, this sets or
|
|
|
|
* unsets the SimpleForkCheck flag in the CHIL API to enable or
|
|
|
|
* disable checking and workarounds for applications that fork().
|
|
|
|
*/
|
|
|
|
#define ENGINE_CTRL_CHIL_NO_LOCKING 101
|
|
|
|
/* This prevents the initialisation function from providing mutex
|
|
|
|
* callbacks to the nCipher library. */
|
|
|
|
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
/* If an ENGINE supports its own specific control commands and wishes the
|
|
|
|
* framework to handle the above 'ENGINE_CMD_***'-manipulation commands on its
|
|
|
|
* behalf, it should supply a null-terminated array of ENGINE_CMD_DEFN entries
|
|
|
|
* to ENGINE_set_cmd_defns(). It should also implement a ctrl() handler that
|
|
|
|
* supports the stated commands (ie. the "cmd_num" entries as described by the
|
|
|
|
* array). NB: The array must be ordered in increasing order of cmd_num.
|
|
|
|
* "null-terminated" means that the last ENGINE_CMD_DEFN element has cmd_num set
|
|
|
|
* to zero and/or cmd_name set to NULL. */
|
|
|
|
typedef struct ENGINE_CMD_DEFN_st
|
|
|
|
{
|
|
|
|
unsigned int cmd_num; /* The command number */
|
|
|
|
const char *cmd_name; /* The command name itself */
|
|
|
|
const char *cmd_desc; /* A short description of the command */
|
|
|
|
unsigned int cmd_flags; /* The input the command expects */
|
|
|
|
} ENGINE_CMD_DEFN;
|
|
|
|
|
2001-04-18 02:01:36 +00:00
|
|
|
/* Generic function pointer */
|
|
|
|
typedef int (*ENGINE_GEN_FUNC_PTR)();
|
|
|
|
/* Generic function pointer taking no arguments */
|
2001-04-18 03:57:05 +00:00
|
|
|
typedef int (*ENGINE_GEN_INT_FUNC_PTR)(ENGINE *);
|
2001-04-18 02:01:36 +00:00
|
|
|
/* Specific control function pointer */
|
2001-04-18 03:57:05 +00:00
|
|
|
typedef int (*ENGINE_CTRL_FUNC_PTR)(ENGINE *, int, long, void *, void (*f)());
|
2001-04-18 02:01:36 +00:00
|
|
|
/* Generic load_key function pointer */
|
2001-05-25 21:08:56 +00:00
|
|
|
typedef EVP_PKEY * (*ENGINE_LOAD_KEY_PTR)(ENGINE *, const char *,
|
2001-06-19 16:12:18 +00:00
|
|
|
UI_METHOD *ui_method, void *callback_data);
|
2001-09-25 21:28:40 +00:00
|
|
|
/* These callback types are for an ENGINE's handler for cipher and digest logic.
|
|
|
|
* These handlers have these prototypes;
|
|
|
|
* int foo(ENGINE *e, const EVP_CIPHER **cipher, const int **nids, int nid);
|
|
|
|
* int foo(ENGINE *e, const EVP_MD **digest, const int **nids, int nid);
|
|
|
|
* Looking at how to implement these handlers in the case of cipher support, if
|
|
|
|
* the framework wants the EVP_CIPHER for 'nid', it will call;
|
|
|
|
* foo(e, &p_evp_cipher, NULL, nid); (return zero for failure)
|
|
|
|
* If the framework wants a list of supported 'nid's, it will call;
|
|
|
|
* foo(e, NULL, &p_nids, 0); (returns number of 'nids' or -1 for error)
|
|
|
|
*/
|
|
|
|
/* Returns to a pointer to the array of supported cipher 'nid's. If the second
|
|
|
|
* parameter is non-NULL it is set to the size of the returned array. */
|
|
|
|
typedef int (*ENGINE_CIPHERS_PTR)(ENGINE *, const EVP_CIPHER **, const int **, int);
|
|
|
|
typedef int (*ENGINE_DIGESTS_PTR)(ENGINE *, const EVP_MD **, const int **, int);
|
2001-04-18 02:01:36 +00:00
|
|
|
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
/* STRUCTURE functions ... all of these functions deal with pointers to ENGINE
|
|
|
|
* structures where the pointers have a "structural reference". This means that
|
|
|
|
* their reference is to allowed access to the structure but it does not imply
|
|
|
|
* that the structure is functional. To simply increment or decrement the
|
|
|
|
* structural reference count, use ENGINE_by_id and ENGINE_free. NB: This is not
|
|
|
|
* required when iterating using ENGINE_get_next as it will automatically
|
|
|
|
* decrement the structural reference count of the "current" ENGINE and
|
|
|
|
* increment the structural reference count of the ENGINE it returns (unless it
|
|
|
|
* is NULL). */
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
/* Get the first/last "ENGINE" type available. */
|
|
|
|
ENGINE *ENGINE_get_first(void);
|
|
|
|
ENGINE *ENGINE_get_last(void);
|
|
|
|
/* Iterate to the next/previous "ENGINE" type (NULL = end of the list). */
|
|
|
|
ENGINE *ENGINE_get_next(ENGINE *e);
|
|
|
|
ENGINE *ENGINE_get_prev(ENGINE *e);
|
|
|
|
/* Add another "ENGINE" type into the array. */
|
|
|
|
int ENGINE_add(ENGINE *e);
|
|
|
|
/* Remove an existing "ENGINE" type from the array. */
|
|
|
|
int ENGINE_remove(ENGINE *e);
|
|
|
|
/* Retrieve an engine from the list by its unique "id" value. */
|
|
|
|
ENGINE *ENGINE_by_id(const char *id);
|
2001-09-25 20:00:51 +00:00
|
|
|
/* Add all the built-in engines. */
|
|
|
|
void ENGINE_load_openssl(void);
|
|
|
|
void ENGINE_load_dynamic(void);
|
2000-11-02 20:33:04 +00:00
|
|
|
void ENGINE_load_cswift(void);
|
|
|
|
void ENGINE_load_chil(void);
|
|
|
|
void ENGINE_load_atalla(void);
|
|
|
|
void ENGINE_load_nuron(void);
|
2000-12-14 21:41:55 +00:00
|
|
|
void ENGINE_load_ubsec(void);
|
2002-02-07 20:44:14 +00:00
|
|
|
void ENGINE_load_aep(void);
|
|
|
|
void ENGINE_load_sureware(void);
|
2002-02-27 22:55:28 +00:00
|
|
|
void ENGINE_load_4758cca(void);
|
2001-08-18 10:22:54 +00:00
|
|
|
void ENGINE_load_openbsd_dev_crypto(void);
|
2000-11-02 20:33:04 +00:00
|
|
|
void ENGINE_load_builtin_engines(void);
|
2000-10-26 21:07:28 +00:00
|
|
|
|
2001-09-25 20:00:51 +00:00
|
|
|
/* Get and set global flags (ENGINE_TABLE_FLAG_***) for the implementation
|
|
|
|
* "registry" handling. */
|
|
|
|
unsigned int ENGINE_get_table_flags(void);
|
|
|
|
void ENGINE_set_table_flags(unsigned int flags);
|
|
|
|
|
|
|
|
/* Manage registration of ENGINEs per "table". For each type, there are 3
|
|
|
|
* functions;
|
|
|
|
* ENGINE_register_***(e) - registers the implementation from 'e' (if it has one)
|
|
|
|
* ENGINE_unregister_***(e) - unregister the implementation from 'e'
|
|
|
|
* ENGINE_register_all_***() - call ENGINE_register_***() for each 'e' in the list
|
|
|
|
* Cleanup is automatically registered from each table when required, so
|
|
|
|
* ENGINE_cleanup() will reverse any "register" operations. */
|
|
|
|
|
|
|
|
int ENGINE_register_RSA(ENGINE *e);
|
|
|
|
void ENGINE_unregister_RSA(ENGINE *e);
|
|
|
|
void ENGINE_register_all_RSA(void);
|
|
|
|
|
|
|
|
int ENGINE_register_DSA(ENGINE *e);
|
|
|
|
void ENGINE_unregister_DSA(ENGINE *e);
|
|
|
|
void ENGINE_register_all_DSA(void);
|
|
|
|
|
2002-02-13 18:21:51 +00:00
|
|
|
int ENGINE_register_ECDSA(ENGINE *e);
|
|
|
|
void ENGINE_unregister_ECDSA(ENGINE *e);
|
|
|
|
void ENGINE_register_all_ECDSA(void);
|
|
|
|
|
2001-09-25 20:00:51 +00:00
|
|
|
int ENGINE_register_DH(ENGINE *e);
|
|
|
|
void ENGINE_unregister_DH(ENGINE *e);
|
|
|
|
void ENGINE_register_all_DH(void);
|
|
|
|
|
|
|
|
int ENGINE_register_RAND(ENGINE *e);
|
|
|
|
void ENGINE_unregister_RAND(ENGINE *e);
|
|
|
|
void ENGINE_register_all_RAND(void);
|
|
|
|
|
2001-09-25 21:28:40 +00:00
|
|
|
int ENGINE_register_ciphers(ENGINE *e);
|
|
|
|
void ENGINE_unregister_ciphers(ENGINE *e);
|
|
|
|
void ENGINE_register_all_ciphers(void);
|
|
|
|
|
|
|
|
int ENGINE_register_digests(ENGINE *e);
|
|
|
|
void ENGINE_unregister_digests(ENGINE *e);
|
|
|
|
void ENGINE_register_all_digests(void);
|
|
|
|
|
2001-09-25 20:00:51 +00:00
|
|
|
/* These functions register all support from the above categories. Note, use of
|
|
|
|
* these functions can result in static linkage of code your application may not
|
|
|
|
* need. If you only need a subset of functionality, consider using more
|
|
|
|
* selective initialisation. */
|
|
|
|
int ENGINE_register_complete(ENGINE *e);
|
|
|
|
int ENGINE_register_all_complete(void);
|
2001-08-18 10:22:54 +00:00
|
|
|
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
/* Send parametrised control commands to the engine. The possibilities to send
|
|
|
|
* down an integer, a pointer to data or a function pointer are provided. Any of
|
|
|
|
* the parameters may or may not be NULL, depending on the command number. In
|
|
|
|
* actuality, this function only requires a structural (rather than functional)
|
|
|
|
* reference to an engine, but many control commands may require the engine be
|
|
|
|
* functional. The caller should be aware of trying commands that require an
|
|
|
|
* operational ENGINE, and only use functional references in such situations. */
|
|
|
|
int ENGINE_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)());
|
|
|
|
|
|
|
|
/* This function tests if an ENGINE-specific command is usable as a "setting".
|
|
|
|
* Eg. in an application's config file that gets processed through
|
|
|
|
* ENGINE_ctrl_cmd_string(). If this returns zero, it is not available to
|
|
|
|
* ENGINE_ctrl_cmd_string(), only ENGINE_ctrl(). */
|
|
|
|
int ENGINE_cmd_is_executable(ENGINE *e, int cmd);
|
|
|
|
|
2001-06-19 16:12:18 +00:00
|
|
|
/* This function works like ENGINE_ctrl() with the exception of taking a
|
|
|
|
* command name instead of a command number, and can handle optional commands.
|
|
|
|
* See the comment on ENGINE_ctrl_cmd_string() for an explanation on how to
|
|
|
|
* use the cmd_name and cmd_optional. */
|
|
|
|
int ENGINE_ctrl_cmd(ENGINE *e, const char *cmd_name,
|
|
|
|
long i, void *p, void (*f)(), int cmd_optional);
|
|
|
|
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
/* This function passes a command-name and argument to an ENGINE. The cmd_name
|
|
|
|
* is converted to a command number and the control command is called using
|
|
|
|
* 'arg' as an argument (unless the ENGINE doesn't support such a command, in
|
|
|
|
* which case no control command is called). The command is checked for input
|
|
|
|
* flags, and if necessary the argument will be converted to a numeric value. If
|
|
|
|
* cmd_optional is non-zero, then if the ENGINE doesn't support the given
|
|
|
|
* cmd_name the return value will be success anyway. This function is intended
|
|
|
|
* for applications to use so that users (or config files) can supply
|
|
|
|
* engine-specific config data to the ENGINE at run-time to control behaviour of
|
|
|
|
* specific engines. As such, it shouldn't be used for calling ENGINE_ctrl()
|
|
|
|
* functions that return data, deal with binary data, or that are otherwise
|
|
|
|
* supposed to be used directly through ENGINE_ctrl() in application code. Any
|
|
|
|
* "return" data from an ENGINE_ctrl() operation in this function will be lost -
|
|
|
|
* the return value is interpreted as failure if the return value is zero,
|
|
|
|
* success otherwise, and this function returns a boolean value as a result. In
|
|
|
|
* other words, vendors of 'ENGINE'-enabled devices should write ENGINE
|
|
|
|
* implementations with parameterisations that work in this scheme, so that
|
|
|
|
* compliant ENGINE-based applications can work consistently with the same
|
|
|
|
* configuration for the same ENGINE-enabled devices, across applications. */
|
|
|
|
int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char *arg,
|
|
|
|
int cmd_optional);
|
|
|
|
|
2001-04-18 02:01:36 +00:00
|
|
|
/* These functions are useful for manufacturing new ENGINE structures. They
|
|
|
|
* don't address reference counting at all - one uses them to populate an ENGINE
|
|
|
|
* structure with personalised implementations of things prior to using it
|
|
|
|
* directly or adding it to the builtin ENGINE list in OpenSSL. These are also
|
|
|
|
* here so that the ENGINE structure doesn't have to be exposed and break binary
|
|
|
|
* compatibility! */
|
2000-10-26 21:07:28 +00:00
|
|
|
ENGINE *ENGINE_new(void);
|
|
|
|
int ENGINE_free(ENGINE *e);
|
|
|
|
int ENGINE_set_id(ENGINE *e, const char *id);
|
|
|
|
int ENGINE_set_name(ENGINE *e, const char *name);
|
2000-11-06 22:15:50 +00:00
|
|
|
int ENGINE_set_RSA(ENGINE *e, const RSA_METHOD *rsa_meth);
|
2000-11-07 13:54:39 +00:00
|
|
|
int ENGINE_set_DSA(ENGINE *e, const DSA_METHOD *dsa_meth);
|
2002-02-13 18:21:51 +00:00
|
|
|
int ENGINE_set_ECDSA(ENGINE *e, const ECDSA_METHOD *ecdsa_meth);
|
2000-11-07 14:30:37 +00:00
|
|
|
int ENGINE_set_DH(ENGINE *e, const DH_METHOD *dh_meth);
|
2001-04-18 02:01:36 +00:00
|
|
|
int ENGINE_set_RAND(ENGINE *e, const RAND_METHOD *rand_meth);
|
2001-09-05 18:32:23 +00:00
|
|
|
int ENGINE_set_destroy_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR destroy_f);
|
2000-10-26 21:07:28 +00:00
|
|
|
int ENGINE_set_init_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR init_f);
|
|
|
|
int ENGINE_set_finish_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR finish_f);
|
|
|
|
int ENGINE_set_ctrl_function(ENGINE *e, ENGINE_CTRL_FUNC_PTR ctrl_f);
|
2001-04-18 02:01:36 +00:00
|
|
|
int ENGINE_set_load_privkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpriv_f);
|
|
|
|
int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f);
|
2001-09-25 21:28:40 +00:00
|
|
|
int ENGINE_set_ciphers(ENGINE *e, ENGINE_CIPHERS_PTR f);
|
|
|
|
int ENGINE_set_digests(ENGINE *e, ENGINE_DIGESTS_PTR f);
|
2001-04-18 02:01:36 +00:00
|
|
|
int ENGINE_set_flags(ENGINE *e, int flags);
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
int ENGINE_set_cmd_defns(ENGINE *e, const ENGINE_CMD_DEFN *defns);
|
This adds 2 things to the ENGINE code.
* "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself
that allows an ENGINE to store its own information there rather than in
global variables. It follows the declarations and implementations used
in RSA code, for better or worse. However there's a problem when storing
state with ENGINEs because, unlike related structure types in OpenSSL,
there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE
is, it has method pointers as its structure elements ... which leads
to;
* ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a
reference to an "implementation" (eg. to get to a hardware device), but
should also be able to maintain state, then this flag can be set by the
ENGINE implementation. The result is that any call to ENGINE_by_id()
will not result in the existing ENGINE being returned (with its
structural reference count incremented) but instead a new copy of the
ENGINE will be returned that can maintain its own state independantly of
any other copies returned in the past or future. Eg. key-generation
might involve a series of ENGINE-specific control commands to set
algorithms, sizes, module-keys, ids, ACLs, etc. A final command could
generate the key. An ENGINE doing this would *have* to declare
ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be
maintained "per-handle" and unaffected by other code having a reference
to the same ENGINE structure.
2001-04-26 19:35:44 +00:00
|
|
|
/* These functions (and the "get" function lower down) allow control over any
|
|
|
|
* per-structure ENGINE data. */
|
|
|
|
int ENGINE_get_ex_new_index(long argl, void *argp, CRYPTO_EX_new *new_func,
|
|
|
|
CRYPTO_EX_dup *dup_func, CRYPTO_EX_free *free_func);
|
|
|
|
int ENGINE_set_ex_data(ENGINE *e, int idx, void *arg);
|
2001-09-25 20:00:51 +00:00
|
|
|
|
|
|
|
/* This function cleans up anything that needs it. Eg. the ENGINE_add() function
|
|
|
|
* automatically ensures the list cleanup function is registered to be called
|
|
|
|
* from ENGINE_cleanup(). Similarly, all ENGINE_register_*** functions ensure
|
|
|
|
* ENGINE_cleanup() will clean up after them. */
|
2001-04-26 16:07:08 +00:00
|
|
|
void ENGINE_cleanup(void);
|
2000-10-26 21:07:28 +00:00
|
|
|
|
2001-04-18 02:01:36 +00:00
|
|
|
/* These return values from within the ENGINE structure. These can be useful
|
|
|
|
* with functional references as well as structural references - it depends
|
|
|
|
* which you obtained. Using the result for functional purposes if you only
|
|
|
|
* obtained a structural reference may be problematic! */
|
|
|
|
const char *ENGINE_get_id(const ENGINE *e);
|
|
|
|
const char *ENGINE_get_name(const ENGINE *e);
|
|
|
|
const RSA_METHOD *ENGINE_get_RSA(const ENGINE *e);
|
|
|
|
const DSA_METHOD *ENGINE_get_DSA(const ENGINE *e);
|
2002-02-13 18:21:51 +00:00
|
|
|
const ECDSA_METHOD *ENGINE_get_ECDSA(const ENGINE *e);
|
2001-04-18 02:01:36 +00:00
|
|
|
const DH_METHOD *ENGINE_get_DH(const ENGINE *e);
|
|
|
|
const RAND_METHOD *ENGINE_get_RAND(const ENGINE *e);
|
2001-09-05 18:32:23 +00:00
|
|
|
ENGINE_GEN_INT_FUNC_PTR ENGINE_get_destroy_function(const ENGINE *e);
|
2001-04-18 02:01:36 +00:00
|
|
|
ENGINE_GEN_INT_FUNC_PTR ENGINE_get_init_function(const ENGINE *e);
|
|
|
|
ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(const ENGINE *e);
|
|
|
|
ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(const ENGINE *e);
|
|
|
|
ENGINE_LOAD_KEY_PTR ENGINE_get_load_privkey_function(const ENGINE *e);
|
|
|
|
ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e);
|
2001-09-25 21:28:40 +00:00
|
|
|
ENGINE_CIPHERS_PTR ENGINE_get_ciphers(const ENGINE *e);
|
|
|
|
ENGINE_DIGESTS_PTR ENGINE_get_digests(const ENGINE *e);
|
|
|
|
const EVP_CIPHER *ENGINE_get_cipher(ENGINE *e, int nid);
|
|
|
|
const EVP_MD *ENGINE_get_digest(ENGINE *e, int nid);
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
const ENGINE_CMD_DEFN *ENGINE_get_cmd_defns(const ENGINE *e);
|
2001-04-18 02:01:36 +00:00
|
|
|
int ENGINE_get_flags(const ENGINE *e);
|
This adds 2 things to the ENGINE code.
* "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself
that allows an ENGINE to store its own information there rather than in
global variables. It follows the declarations and implementations used
in RSA code, for better or worse. However there's a problem when storing
state with ENGINEs because, unlike related structure types in OpenSSL,
there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE
is, it has method pointers as its structure elements ... which leads
to;
* ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a
reference to an "implementation" (eg. to get to a hardware device), but
should also be able to maintain state, then this flag can be set by the
ENGINE implementation. The result is that any call to ENGINE_by_id()
will not result in the existing ENGINE being returned (with its
structural reference count incremented) but instead a new copy of the
ENGINE will be returned that can maintain its own state independantly of
any other copies returned in the past or future. Eg. key-generation
might involve a series of ENGINE-specific control commands to set
algorithms, sizes, module-keys, ids, ACLs, etc. A final command could
generate the key. An ENGINE doing this would *have* to declare
ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be
maintained "per-handle" and unaffected by other code having a reference
to the same ENGINE structure.
2001-04-26 19:35:44 +00:00
|
|
|
void *ENGINE_get_ex_data(const ENGINE *e, int idx);
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
/* FUNCTIONAL functions. These functions deal with ENGINE structures
|
|
|
|
* that have (or will) be initialised for use. Broadly speaking, the
|
|
|
|
* structural functions are useful for iterating the list of available
|
|
|
|
* engine types, creating new engine types, and other "list" operations.
|
|
|
|
* These functions actually deal with ENGINEs that are to be used. As
|
|
|
|
* such these functions can fail (if applicable) when particular
|
|
|
|
* engines are unavailable - eg. if a hardware accelerator is not
|
|
|
|
* attached or not functioning correctly. Each ENGINE has 2 reference
|
|
|
|
* counts; structural and functional. Every time a functional reference
|
|
|
|
* is obtained or released, a corresponding structural reference is
|
|
|
|
* automatically obtained or released too. */
|
|
|
|
|
|
|
|
/* Initialise a engine type for use (or up its reference count if it's
|
|
|
|
* already in use). This will fail if the engine is not currently
|
|
|
|
* operational and cannot initialise. */
|
|
|
|
int ENGINE_init(ENGINE *e);
|
|
|
|
/* Free a functional reference to a engine type. This does not require
|
|
|
|
* a corresponding call to ENGINE_free as it also releases a structural
|
|
|
|
* reference. */
|
|
|
|
int ENGINE_finish(ENGINE *e);
|
|
|
|
|
|
|
|
/* The following functions handle keys that are stored in some secondary
|
|
|
|
* location, handled by the engine. The storage may be on a card or
|
|
|
|
* whatever. */
|
|
|
|
EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id,
|
2001-06-19 16:12:18 +00:00
|
|
|
UI_METHOD *ui_method, void *callback_data);
|
2000-10-26 21:07:28 +00:00
|
|
|
EVP_PKEY *ENGINE_load_public_key(ENGINE *e, const char *key_id,
|
2001-06-19 16:12:18 +00:00
|
|
|
UI_METHOD *ui_method, void *callback_data);
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
/* This returns a pointer for the current ENGINE structure that
|
|
|
|
* is (by default) performing any RSA operations. The value returned
|
|
|
|
* is an incremented reference, so it should be free'd (ENGINE_finish)
|
|
|
|
* before it is discarded. */
|
|
|
|
ENGINE *ENGINE_get_default_RSA(void);
|
|
|
|
/* Same for the other "methods" */
|
|
|
|
ENGINE *ENGINE_get_default_DSA(void);
|
2002-02-13 18:21:51 +00:00
|
|
|
ENGINE *ENGINE_get_default_ECDSA(void);
|
2000-10-26 21:07:28 +00:00
|
|
|
ENGINE *ENGINE_get_default_DH(void);
|
|
|
|
ENGINE *ENGINE_get_default_RAND(void);
|
2001-09-25 21:28:40 +00:00
|
|
|
/* These functions can be used to get a functional reference to perform
|
|
|
|
* ciphering or digesting corresponding to "nid". */
|
|
|
|
ENGINE *ENGINE_get_cipher_engine(int nid);
|
|
|
|
ENGINE *ENGINE_get_digest_engine(int nid);
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
/* This sets a new default ENGINE structure for performing RSA
|
|
|
|
* operations. If the result is non-zero (success) then the ENGINE
|
|
|
|
* structure will have had its reference count up'd so the caller
|
|
|
|
* should still free their own reference 'e'. */
|
|
|
|
int ENGINE_set_default_RSA(ENGINE *e);
|
2002-01-22 02:06:33 +00:00
|
|
|
int ENGINE_set_default_string(ENGINE *e, const char *list);
|
2000-10-26 21:07:28 +00:00
|
|
|
/* Same for the other "methods" */
|
|
|
|
int ENGINE_set_default_DSA(ENGINE *e);
|
2002-02-13 18:21:51 +00:00
|
|
|
int ENGINE_set_default_ECDSA(ENGINE *e);
|
2000-10-26 21:07:28 +00:00
|
|
|
int ENGINE_set_default_DH(ENGINE *e);
|
|
|
|
int ENGINE_set_default_RAND(ENGINE *e);
|
2001-09-25 21:28:40 +00:00
|
|
|
int ENGINE_set_default_ciphers(ENGINE *e);
|
|
|
|
int ENGINE_set_default_digests(ENGINE *e);
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
/* The combination "set" - the flags are bitwise "OR"d from the
|
2001-09-25 20:00:51 +00:00
|
|
|
* ENGINE_METHOD_*** defines above. As with the "ENGINE_register_complete()"
|
|
|
|
* function, this function can result in unnecessary static linkage. If your
|
|
|
|
* application requires only specific functionality, consider using more
|
|
|
|
* selective functions. */
|
2000-10-26 21:07:28 +00:00
|
|
|
int ENGINE_set_default(ENGINE *e, unsigned int flags);
|
|
|
|
|
2002-01-21 03:02:36 +00:00
|
|
|
void ENGINE_add_conf_module(void);
|
|
|
|
|
2001-09-25 20:00:51 +00:00
|
|
|
/* Deprecated functions ... */
|
|
|
|
/* int ENGINE_clear_defaults(void); */
|
2001-08-18 13:53:01 +00:00
|
|
|
|
2001-09-03 19:15:29 +00:00
|
|
|
/**************************/
|
|
|
|
/* DYNAMIC ENGINE SUPPORT */
|
|
|
|
/**************************/
|
|
|
|
|
|
|
|
/* Binary/behaviour compatibility levels */
|
|
|
|
#define OSSL_DYNAMIC_VERSION (unsigned long)0x00010100
|
|
|
|
/* Binary versions older than this are too old for us (whether we're a loader or
|
|
|
|
* a loadee) */
|
|
|
|
#define OSSL_DYNAMIC_OLDEST (unsigned long)0x00010100
|
|
|
|
|
|
|
|
/* When compiling an ENGINE entirely as an external shared library, loadable by
|
|
|
|
* the "dynamic" ENGINE, these types are needed. The 'dynamic_fns' structure
|
|
|
|
* type provides the calling application's (or library's) error functionality
|
|
|
|
* and memory management function pointers to the loaded library. These should
|
|
|
|
* be used/set in the loaded library code so that the loading application's
|
|
|
|
* 'state' will be used/changed in all operations. */
|
2001-09-04 21:25:17 +00:00
|
|
|
typedef void *(*dyn_MEM_malloc_cb)(size_t);
|
|
|
|
typedef void *(*dyn_MEM_realloc_cb)(void *, size_t);
|
|
|
|
typedef void (*dyn_MEM_free_cb)(void *);
|
2001-09-03 19:15:29 +00:00
|
|
|
typedef struct st_dynamic_MEM_fns {
|
2001-09-04 21:25:17 +00:00
|
|
|
dyn_MEM_malloc_cb malloc_cb;
|
|
|
|
dyn_MEM_realloc_cb realloc_cb;
|
|
|
|
dyn_MEM_free_cb free_cb;
|
2001-09-03 19:15:29 +00:00
|
|
|
} dynamic_MEM_fns;
|
2001-09-04 21:25:17 +00:00
|
|
|
/* FIXME: Perhaps the memory and locking code (crypto.h) should declare and use
|
|
|
|
* these types so we (and any other dependant code) can simplify a bit?? */
|
|
|
|
typedef void (*dyn_lock_locking_cb)(int,int,const char *,int);
|
|
|
|
typedef int (*dyn_lock_add_lock_cb)(int*,int,int,const char *,int);
|
|
|
|
typedef struct CRYPTO_dynlock_value *(*dyn_dynlock_create_cb)(
|
|
|
|
const char *,int);
|
|
|
|
typedef void (*dyn_dynlock_lock_cb)(int,struct CRYPTO_dynlock_value *,
|
|
|
|
const char *,int);
|
|
|
|
typedef void (*dyn_dynlock_destroy_cb)(struct CRYPTO_dynlock_value *,
|
|
|
|
const char *,int);
|
|
|
|
typedef struct st_dynamic_LOCK_fns {
|
|
|
|
dyn_lock_locking_cb lock_locking_cb;
|
|
|
|
dyn_lock_add_lock_cb lock_add_lock_cb;
|
|
|
|
dyn_dynlock_create_cb dynlock_create_cb;
|
|
|
|
dyn_dynlock_lock_cb dynlock_lock_cb;
|
|
|
|
dyn_dynlock_destroy_cb dynlock_destroy_cb;
|
|
|
|
} dynamic_LOCK_fns;
|
|
|
|
/* The top-level structure */
|
2001-09-03 19:15:29 +00:00
|
|
|
typedef struct st_dynamic_fns {
|
|
|
|
const ERR_FNS *err_fns;
|
|
|
|
const CRYPTO_EX_DATA_IMPL *ex_data_fns;
|
|
|
|
dynamic_MEM_fns mem_fns;
|
2001-09-04 21:25:17 +00:00
|
|
|
dynamic_LOCK_fns lock_fns;
|
2001-09-03 19:15:29 +00:00
|
|
|
} dynamic_fns;
|
|
|
|
|
|
|
|
/* The version checking function should be of this prototype. NB: The
|
|
|
|
* ossl_version value passed in is the OSSL_DYNAMIC_VERSION of the loading code.
|
|
|
|
* If this function returns zero, it indicates a (potential) version
|
|
|
|
* incompatibility and the loaded library doesn't believe it can proceed.
|
|
|
|
* Otherwise, the returned value is the (latest) version supported by the
|
|
|
|
* loading library. The loader may still decide that the loaded code's version
|
|
|
|
* is unsatisfactory and could veto the load. The function is expected to
|
|
|
|
* be implemented with the symbol name "v_check", and a default implementation
|
|
|
|
* can be fully instantiated with IMPLEMENT_DYNAMIC_CHECK_FN(). */
|
|
|
|
typedef unsigned long (*dynamic_v_check_fn)(unsigned long ossl_version);
|
|
|
|
#define IMPLEMENT_DYNAMIC_CHECK_FN() \
|
|
|
|
unsigned long v_check(unsigned long v) { \
|
|
|
|
if(v >= OSSL_DYNAMIC_OLDEST) return OSSL_DYNAMIC_VERSION; \
|
|
|
|
return 0; }
|
|
|
|
|
|
|
|
/* This function is passed the ENGINE structure to initialise with its own
|
|
|
|
* function and command settings. It should not adjust the structural or
|
|
|
|
* functional reference counts. If this function returns zero, (a) the load will
|
|
|
|
* be aborted, (b) the previous ENGINE state will be memcpy'd back onto the
|
|
|
|
* structure, and (c) the shared library will be unloaded. So implementations
|
|
|
|
* should do their own internal cleanup in failure circumstances otherwise they
|
|
|
|
* could leak. The 'id' parameter, if non-NULL, represents the ENGINE id that
|
|
|
|
* the loader is looking for. If this is NULL, the shared library can choose to
|
|
|
|
* return failure or to initialise a 'default' ENGINE. If non-NULL, the shared
|
|
|
|
* library must initialise only an ENGINE matching the passed 'id'. The function
|
|
|
|
* is expected to be implemented with the symbol name "bind_engine". A standard
|
|
|
|
* implementation can be instantiated with IMPLEMENT_DYNAMIC_BIND_FN(fn) where
|
|
|
|
* the parameter 'fn' is a callback function that populates the ENGINE structure
|
|
|
|
* and returns an int value (zero for failure). 'fn' should have prototype;
|
|
|
|
* [static] int fn(ENGINE *e, const char *id); */
|
|
|
|
typedef int (*dynamic_bind_engine)(ENGINE *e, const char *id,
|
|
|
|
const dynamic_fns *fns);
|
|
|
|
#define IMPLEMENT_DYNAMIC_BIND_FN(fn) \
|
|
|
|
int bind_engine(ENGINE *e, const char *id, const dynamic_fns *fns) { \
|
|
|
|
if(!CRYPTO_set_mem_functions(fns->mem_fns.malloc_cb, \
|
|
|
|
fns->mem_fns.realloc_cb, fns->mem_fns.free_cb)) \
|
|
|
|
return 0; \
|
2001-09-04 21:25:17 +00:00
|
|
|
CRYPTO_set_locking_callback(fns->lock_fns.lock_locking_cb); \
|
|
|
|
CRYPTO_set_add_lock_callback(fns->lock_fns.lock_add_lock_cb); \
|
|
|
|
CRYPTO_set_dynlock_create_callback(fns->lock_fns.dynlock_create_cb); \
|
|
|
|
CRYPTO_set_dynlock_lock_callback(fns->lock_fns.dynlock_lock_cb); \
|
|
|
|
CRYPTO_set_dynlock_destroy_callback(fns->lock_fns.dynlock_destroy_cb); \
|
2001-09-03 19:15:29 +00:00
|
|
|
if(!CRYPTO_set_ex_data_implementation(fns->ex_data_fns)) \
|
|
|
|
return 0; \
|
|
|
|
if(!ERR_set_implementation(fns->err_fns)) return 0; \
|
|
|
|
if(!fn(e,id)) return 0; \
|
|
|
|
return 1; }
|
2001-08-18 10:22:54 +00:00
|
|
|
|
2000-10-26 21:07:28 +00:00
|
|
|
/* BEGIN ERROR CODES */
|
|
|
|
/* The following lines are auto generated by the script mkerr.pl. Any changes
|
|
|
|
* made after this point may be overwritten when the script is next run.
|
|
|
|
*/
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
void ERR_load_ENGINE_strings(void);
|
2002-01-24 16:20:42 +00:00
|
|
|
|
2000-10-26 21:07:28 +00:00
|
|
|
/* Error codes for the ENGINE functions. */
|
|
|
|
|
|
|
|
/* Function codes. */
|
2001-09-03 19:15:29 +00:00
|
|
|
#define ENGINE_F_DYNAMIC_CTRL 180
|
|
|
|
#define ENGINE_F_DYNAMIC_GET_DATA_CTX 181
|
|
|
|
#define ENGINE_F_DYNAMIC_LOAD 182
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_ENGINE_ADD 105
|
|
|
|
#define ENGINE_F_ENGINE_BY_ID 106
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
#define ENGINE_F_ENGINE_CMD_IS_EXECUTABLE 170
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_ENGINE_CTRL 142
|
2001-06-19 16:12:18 +00:00
|
|
|
#define ENGINE_F_ENGINE_CTRL_CMD 178
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
#define ENGINE_F_ENGINE_CTRL_CMD_STRING 171
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_ENGINE_FINISH 107
|
|
|
|
#define ENGINE_F_ENGINE_FREE 108
|
2001-09-25 21:28:40 +00:00
|
|
|
#define ENGINE_F_ENGINE_GET_CIPHER 185
|
2001-04-26 15:45:12 +00:00
|
|
|
#define ENGINE_F_ENGINE_GET_DEFAULT_TYPE 177
|
2001-09-25 21:28:40 +00:00
|
|
|
#define ENGINE_F_ENGINE_GET_DIGEST 186
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_ENGINE_GET_NEXT 115
|
|
|
|
#define ENGINE_F_ENGINE_GET_PREV 116
|
|
|
|
#define ENGINE_F_ENGINE_INIT 119
|
|
|
|
#define ENGINE_F_ENGINE_LIST_ADD 120
|
|
|
|
#define ENGINE_F_ENGINE_LIST_REMOVE 121
|
|
|
|
#define ENGINE_F_ENGINE_LOAD_PRIVATE_KEY 150
|
|
|
|
#define ENGINE_F_ENGINE_LOAD_PUBLIC_KEY 151
|
2002-01-21 03:02:36 +00:00
|
|
|
#define ENGINE_F_ENGINE_MODULE_INIT 187
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_ENGINE_NEW 122
|
|
|
|
#define ENGINE_F_ENGINE_REMOVE 123
|
2002-01-22 01:40:18 +00:00
|
|
|
#define ENGINE_F_ENGINE_SET_DEFAULT_STRING 189
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_ENGINE_SET_DEFAULT_TYPE 126
|
|
|
|
#define ENGINE_F_ENGINE_SET_ID 129
|
|
|
|
#define ENGINE_F_ENGINE_SET_NAME 130
|
2001-09-25 20:00:51 +00:00
|
|
|
#define ENGINE_F_ENGINE_TABLE_REGISTER 184
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_ENGINE_UNLOAD_KEY 152
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
#define ENGINE_F_INT_CTRL_HELPER 172
|
2002-01-21 03:02:36 +00:00
|
|
|
#define ENGINE_F_INT_ENGINE_CONFIGURE 188
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_F_LOG_MESSAGE 141
|
2001-09-03 19:15:29 +00:00
|
|
|
#define ENGINE_F_SET_DATA_CTX 183
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
/* Reason codes. */
|
|
|
|
#define ENGINE_R_ALREADY_LOADED 100
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
#define ENGINE_R_ARGUMENT_IS_NOT_A_NUMBER 133
|
|
|
|
#define ENGINE_R_CMD_NOT_EXECUTABLE 134
|
|
|
|
#define ENGINE_R_COMMAND_TAKES_INPUT 135
|
|
|
|
#define ENGINE_R_COMMAND_TAKES_NO_INPUT 136
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_R_CONFLICTING_ENGINE_ID 103
|
|
|
|
#define ENGINE_R_CTRL_COMMAND_NOT_IMPLEMENTED 119
|
2001-04-26 15:45:12 +00:00
|
|
|
#define ENGINE_R_DH_NOT_IMPLEMENTED 139
|
|
|
|
#define ENGINE_R_DSA_NOT_IMPLEMENTED 140
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_R_DSO_FAILURE 104
|
|
|
|
#define ENGINE_R_DSO_NOT_FOUND 132
|
2002-01-21 03:02:36 +00:00
|
|
|
#define ENGINE_R_ENGINES_SECTION_ERROR 148
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_R_ENGINE_IS_NOT_IN_LIST 105
|
2002-01-21 03:02:36 +00:00
|
|
|
#define ENGINE_R_ENGINE_SECTION_ERROR 149
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_R_FAILED_LOADING_PRIVATE_KEY 128
|
|
|
|
#define ENGINE_R_FAILED_LOADING_PUBLIC_KEY 129
|
|
|
|
#define ENGINE_R_FINISH_FAILED 106
|
|
|
|
#define ENGINE_R_GET_HANDLE_FAILED 107
|
|
|
|
#define ENGINE_R_ID_OR_NAME_MISSING 108
|
|
|
|
#define ENGINE_R_INIT_FAILED 109
|
|
|
|
#define ENGINE_R_INTERNAL_LIST_ERROR 110
|
2001-09-03 19:15:29 +00:00
|
|
|
#define ENGINE_R_INVALID_ARGUMENT 143
|
Some BIG tweaks to ENGINE code.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
2001-04-19 00:41:55 +00:00
|
|
|
#define ENGINE_R_INVALID_CMD_NAME 137
|
|
|
|
#define ENGINE_R_INVALID_CMD_NUMBER 138
|
2002-03-06 14:15:13 +00:00
|
|
|
#define ENGINE_R_INVALID_INIT_VALUE 151
|
2002-01-22 01:40:18 +00:00
|
|
|
#define ENGINE_R_INVALID_STRING 150
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_R_NOT_INITIALISED 117
|
|
|
|
#define ENGINE_R_NOT_LOADED 112
|
|
|
|
#define ENGINE_R_NO_CONTROL_FUNCTION 120
|
2001-09-03 19:15:29 +00:00
|
|
|
#define ENGINE_R_NO_INDEX 144
|
2000-10-26 21:07:28 +00:00
|
|
|
#define ENGINE_R_NO_LOAD_FUNCTION 125
|
|
|
|
#define ENGINE_R_NO_REFERENCE 130
|
|
|
|
#define ENGINE_R_NO_SUCH_ENGINE 116
|
|
|
|
#define ENGINE_R_NO_UNLOAD_FUNCTION 126
|
|
|
|
#define ENGINE_R_PROVIDE_PARAMETERS 113
|
2001-04-26 15:45:12 +00:00
|
|
|
#define ENGINE_R_RSA_NOT_IMPLEMENTED 141
|
2001-09-25 21:28:40 +00:00
|
|
|
#define ENGINE_R_UNIMPLEMENTED_CIPHER 146
|
|
|
|
#define ENGINE_R_UNIMPLEMENTED_DIGEST 147
|
2001-09-03 19:15:29 +00:00
|
|
|
#define ENGINE_R_VERSION_INCOMPATIBILITY 145
|
2000-10-26 21:07:28 +00:00
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
#endif
|