Lines Matching refs:to
14 users who need to maintain or support existing ENGINE implementations.
16 via providers, and existing engines should be converted to providers
29 In addition, dynamic binding to external ENGINE implementations is now
42 With respect to EVP, this relates to support for ciphers and digests in
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
55 extensible way for ENGINEs to define their own "configuration" mechanisms
56 that are specific to a given ENGINE (eg. for a particular hardware
62 Presently however, applications must use the ENGINE API itself to provide
83 the vendors of the devices these ENGINEs support have contributed to the
85 guarantees) have experience in using the ENGINE support to drive their
87 behaviour in using a specific ENGINE implementation should be sent to the
91 none of this is possible, or the problem seems to be something about the
92 ENGINE API itself (ie. not necessarily specific to a particular ENGINE
93 implementation) then you should mail complete details to the relevant
94 OpenSSL mailing list. For a definition of "complete details", refer to
95 the OpenSSL "README" file. As for which list to send it to:
107 openssl utility commands to use anything else through a new command line
108 switch called "-engine". Also, if you want to use the ENGINE support in
109 your own code to do something similar, you must likewise explicitly
113 may need to be applied to an ENGINE for it to function as expected/hoped.
114 The recommended way of doing this is for the application to support
118 also) to provide any such input directly to the ENGINE implementation.
119 This way, applications do not need to know anything specific to any
120 device, they only need to provide the means to carry such user/admin
121 input through to the ENGINE in question. Ie. this connects *you* (and
122 your helpdesk) to the specific ENGINE implementation (and device), and
123 allows application authors to not get buried in hassle supporting
133 The new "dynamic" ENGINE provides a low-overhead way to support ENGINE
136 have known problems and you wish to use a newer version with an existing
139 wish to use, and the ENGINE provider (eg. hardware vendor) is providing
141 The other use-case for "dynamic" is with applications that wish to
143 ENGINE implementations from OpenSSL, but instead leaves you to provide
145 shared-libraries. It should be possible for hardware vendors to provide
146 their own shared-libraries to support arbitrary hardware to work with
149 announced for versions later than the one you need, ask the vendor to
150 backport their ENGINE to the version you need.
159 way at all) does not get confused by 'dynamic' being used to do many
162 to keep order). The dynamic ENGINE itself provides absolutely no
163 cryptographic functionality, and any attempt to "initialise" the ENGINE
165 that can be used to control how it will load an external ENGINE
171 The "SO_PATH" control command should be used to identify the
176 multiple ENGINEs, but if you know the engine id you expect to be using,
177 it doesn't hurt to specify it (and this provides a sanity check if
179 loaded ENGINE to be discoverable by application code later on using the
183 that uses the settings from any previous commands to actually *load*
209 Or to simply see the list of commands supported by the "foo" ENGINE;
217 "control commands" mechanism, will provide some way for you to pass
218 such commands through to ENGINEs. As such, you would select "dynamic"
219 as the ENGINE to use, and the parameters/commands you pass would
222 Whilst the syntax demonstrated in "openssl engine" uses a colon to
227 might be issued to an ENGINE *after* it has been initialised for use.
228 Eg. if an ENGINE implementation requires a smart-card to be inserted
229 during initialisation (or a PIN to be typed, or whatever), there may be
230 a control command you can issue afterwards to "forget" the smart-card
234 value. In such a case, the command would be passed to the ENGINE after
248 would have to use "dynamic" to load any such ENGINE - but on the other
266 already specify the relevant flags to do this, but you should consult
273 1. "cd" to the crypto/engine/ directory of a pre-compiled OpenSSL
277 flags (and syntax) being used to build normally. Eg;
283 3. Manually enter the same compilation line to compile the
286 - add "-DENGINE_DYNAMIC_SUPPORT" to the command line switches,
287 - change the output file from "hw_atalla.o" to something new,
291 OpenSSL libraries to resolve any dependencies. The syntax for doing
293 known well to anyone who has worked with shared-library portability
308 the "-t" switch to the utility if you want it to try and initialise
309 the atalla ENGINE for use to test any possible hardware/driver issues.
317 to write at memory address 0x00000002.
