Geoff Thorpe wrote:
>
> On Tue, 31 Oct 2000, Ben Laurie wrote:
>
>
> BTW: Right now, all the existing engine implementations typically work
> immediately without any "setup" beyond what they work out for themselves
> before, during, or after initialisation.
>
Indeed, but its possible to imagine various engines that require rather
complex settings possibly on a per instance basis. Lets say for example
we have a PKCS#11 engine. It might need to know the location of the
PKCS#11 library, whether to login immediately and probably a bunch of
other things I haven't thought of yet. We might also have multiple
instances using separate PKCS#11 libraries too.
IMHO a situation to avoid is one where this kind of thing is handled
only via engine specific ENGINE_ctrl() functions such that an engine
aware application needs to be modified to handle newer engines.
I can think of several ways of handling this. One is to just give the
engine access to a config file and let it decide how to interpret it. At
an application level we could have (say) an ENGINE_load_config() high
level function that can be used to decide which engines to load, some
things like default methods to override and sections containing engine
specific configuration.
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
