Lines Matching +full:application +full:- +full:specific
5 ----------------
12 by the [PROVIDER API](README-PROVIDERS.md), it is deprecated in OpenSSL
19 Built-in ENGINE implementations
20 -------------------------------
22 There are currently built-in ENGINE implementations for the following
40 --------------------------
48 ---------------------
51 form of "control commands". These allow an application to expose to the
53 implementation supports, and for an application to directly feed string
54 based input to those ENGINEs, in the form of name-value pairs. This is an
56 that are specific to a given ENGINE (eg. for a particular hardware
57 device) but that should be consistent across *all* OpenSSL-based
64 with the various compiled-in ENGINEs (see further down for dynamic
67 openssl engine -vvvv
70 -------------
73 self-documenting, but some summaries and usage instructions are needed -
78 STABILITY & BUG-REPORTS
86 devices from common OpenSSL-based applications. Bugs and/or inexplicable
87 behaviour in using a specific ENGINE implementation should be sent to the
92 ENGINE API itself (ie. not necessarily specific to a particular ENGINE
97 * openssl-users: if you are *using* the ENGINE abstraction, either in an
98 pre-compiled application or in your own application code.
100 * openssl-dev: if you are discussing problems with OpenSSL source code.
108 switch called "-engine". Also, if you want to use the ENGINE support in
114 The recommended way of doing this is for the application to support
116 whatever configuration primitives it might require and the application
119 This way, applications do not need to know anything specific to any
122 your helpdesk) to the specific ENGINE implementation (and device), and
123 allows application authors to not get buried in hassle supporting
128 instructions are available by specifying the "-?" command line switch.
133 The new "dynamic" ENGINE provides a low-overhead way to support ENGINE
134 implementations that aren't pre-compiled and linked into OpenSSL-based
135 applications. This could be because existing compiled-in implementations
137 application. It could equally be because the application (or OpenSSL
140 you with a self-contained implementation in the form of a shared-library.
141 The other use-case for "dynamic" is with applications that wish to
142 maintain the smallest foot-print possible and so do not link in various
144 them, if you want them, in the form of "dynamic"-loadable
145 shared-libraries. It should be possible for hardware vendors to provide
146 their own shared-libraries to support arbitrary hardware to work with
148 application based on 0.9.7 (or later) and the support you desire is only
153 ------------------------
156 every time application code asks for the 'dynamic' ENGINE, it in fact
157 gets its own copy of it. As such, multi-threaded code (or code that
158 multiplexes multiple uses of 'dynamic' in a single application in any
166 implementation from a shared-library. To see these control commands,
167 use the command-line;
169 openssl engine -vvvv dynamic
172 shared-library that contains the ENGINE implementation, and "NO_VCHECK"
175 "ID" is probably only needed if a shared-library implements
179 loaded ENGINE to be discoverable by application code later on using the
180 ENGINE's "id". For most applications, this isn't necessary - but some
181 application authors may have nifty reasons for using it. The "LOAD"
184 the shared-library ENGINE implementation. If this command succeeds, the
186 that has been loaded from the shared-library. As such, any control
188 normal. Eg. if ENGINE "foo" is implemented in the shared-library
204 -pre SO_PATH:/lib/libfoo.so \
205 -pre ID:foo \
206 -pre LOAD \
207 -pre "CMD_FOO:some input data"
211 openssl engine -vvvv dynamic \
212 -pre SO_PATH:/lib/libfoo.so \
213 -pre ID:foo \
214 -pre LOAD
220 control the *actual* ENGINE used. Each command is actually a name-value
225 key-value pair may be used by some applications). The reason for the
226 "-pre" syntax in the "openssl engine" utility is that some commands
228 Eg. if an ENGINE implementation requires a smart-card to be inserted
230 a control command you can issue afterwards to "forget" the smart-card
232 applications such as web-servers, where potentially volatile code may
235 it has been initialised for use, and so the "-post" switch would be
238 ("-pre" is almost always what you're after, in reality).
241 ----------------------------------
243 This question is trickier - currently OpenSSL bundles various ENGINE
244 implementations that are statically built in, and any application that
248 would have to use "dynamic" to load any such ENGINE - but on the other
258 a shared-library that can be loaded by "dynamic" isn't automated in
260 Such a shared-library can either be built with any OpenSSL code it
265 position-independent code ("PIC"). The default OpenSSL compilation may
270 crypto/engine/ directory as a shared-library for use via the "dynamic"
273 1. "cd" to the crypto/engine/ directory of a pre-compiled OpenSSL
285 * add "-DENGINE_DYNAMIC_SUPPORT" to the command line switches,
289 4. Link "tmp_atalla.o" into a shared-library using the top-level
292 known well to anyone who has worked with shared-library portability
295 gcc -shared -o dyn_atalla.so tmp_atalla.o -L../.. -lcrypto
298 previous section. Eg. from the top-level directory, you might try
300 apps/openssl engine -vvvv dynamic \
301 -pre SO_PATH:./crypto/engine/dyn_atalla.so -pre LOAD
303 If the shared-library loads successfully, you will see both "-pre"
305 displayed (because of "-vvvv") will be the control commands for the
307 the "-t" switch to the utility if you want it to try and initialise
315 -engine cswift" generated errors. If the DSO gets enabled, an attempt is made