At 11:29 AM 12/11/02 -0500, Geoff Thorpe wrote: >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?
The nCipher CHIL library doesn't implement locks itself for similar reasons to OpenSSL, * It doesn't know the applications threading behaviour (though it could be told) * The application might have it's own locking primitives which it wants CHIL to use, e.g to enable debuging of lock conflicts etc. This is the same argument for allowing the application to supply malloc/free function upcalls. However I think it is fair to say that a CHIL implementation could include OS specfic locking implementations for the case when it is told that the app wants to be multithreaded but doesn't want to supply it's own locking upcalls. The same applies with OpenSSL, it would be friendly for it to supply OS specific locking implementations in the case when configure has detected a pthreads library (say) and hasn't provided any locking upcalls. My reason for wanting the chil engine code to be allowed to use the static openssl locking call if the dynlock upcalls are not provided is simply a pragmatic one, it is the simplest way of ensuring that current multithreaded openssl apps will "just" work with the chil engine. As it stands they won't work and we will have to ensure that the appropriate changes are made to all of these apps (possibly just Apache2). I don't think that the chil engine code using static locks is the right way to go permanently, but then I don't think openssl requiring apps to implement anything other that the dynamic locks is the right way to go either. Bertie ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
