Richard Levitte - VMS Whacker wrote: > > > The only thing that troubles me then is that the plug-in (dynamically > loadable, right?) would have to share certain structures with OpenSSL, > which means that we'd better define those structures in a way that > they won't need change after they are set in stone, or that something > clever is done so they can extend without breaking compatibility. > That, or have the plug-ins keep a very sharp eye on the version of the > loading OpenSSL to avoid version clashes (something we do with engines > today, sadly). >
Well they don't have to be dynamically loadable. At least one plug-in or plug-in class should be built in. The in memory plug-in would be a good candidate for that or the hash class: whichever one is used to emulate the current PEM file/directory/index mess. [Now I come to think of it the in memory plug-in could be an instance of the hash class which used LHASH for its hash database... however using that for a typical one or two certificate smart card is a bit of overkill.] Usually though they will be dynamically loadable. It appears, at least on the face of it, that the actual parts of the library they would use (ASN1 is one case) are hard to set in stone so we may be stuck with checking versions, at least before OpenSSL 1.0 . Some of the plug-in classes could themselves load DSOs where the functionality could be made backwards compatible though. The hash class could have an API which makes little or no reference to OpenSSL insternal structures at all. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.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]
