Hi there, * Bertie ([EMAIL PROTECTED]) wrote: > At 10:00 AM 12/11/02 +0100, Richard Levitte - VMS Whacker wrote: > >bertie> Yep, this solution works if you are an application developer > >bertie> wanting to use chil engine. This is not much help if you are > >bertie> say an Apache user who wanted to use an nCipher HSM to protect > >bertie> their Apache keys - They will get your error message but won't > >bertie> be able to fix the problem, they will phone nCipher support > >bertie> and we'll end up giving them a patch to apply. > > > >And I assume application author will be notified (for what we > >discussed, that would be the Apache team and Ralf (author of mod_ssl), > >right?), or are you skipping that kind of step?
Just catching up on all this, but something seems a bit strange to me about the fundamental reliance on OpenSSL-sponsored dynamic locks. The point is this: ENGINE is a bridge between OpenSSL and an external module's native, proprietary, separated drivers and libs. If the chil engine is going to require locking assurances for its internal operation, and can't function without (eg. in the instance that OpenSSL doesn't provide dynamic locks), then why aren't they implemented in the nCipher/chil shared-library? Eg. file semaphores, pthread mutexes, or anything else you can lay your hands on when you build your library for a given target platform. As it is, I think nCipher has more ability to tweak this support on a per-platform basis than OpenSSL does - as you are targetting a variety of other highly platform-dependant features already (eg. you have to communicate with the kernel drivers!). A mutex is a mutex, whether it's "supplied" by the application or implemented in the bowels of your hardware support. I think the pragmatic approach is to implement your own - and it's more likely to lead you to better locking and scheduling mechanisms in the rest of your hardware libs/drivers anyway if you have full control over the implementation details. NB: the ideal ENGINE is nothing more than a very small shim to the "native" library supporting the corresponding (hardware) module - in fact this is most of the motivation for the current "dynamic" ENGINE stuff. We can cut the middle man out and simply have vendors supply ENGINE implementations natively to their clients in the form of shared libraries (closed-source if they want - it's not our problem) and OpenSSL's ENGINE architecture can bind to those libraries directly. Ie. no need for any per-ENGINE shims built into OpenSSL. But perhaps I'm missing something salient here? Does that thought make sense to you from the chil point of view? Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
