On Sep 11, 2008, at 7:04 AM, [EMAIL PROTECTED] via RT wrote: > On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote: >> 2) Have the engine provide its own callbacks that get set in case the >> application does not provide (presumably more suitable) alternatives: > > I think it would be entirely sensible for OpenSSL to offer a build- > time > configuration option to implement default locking/id callbacks using > pthread functions like this. It would be necessary also to link > libcrypto against -lpthread and/or use the -pthread compiler flag, to > avoid only picking up dummy libc stubs on some platforms. > > That seems far better than requiring every single OpenSSL > application to > implement exactly the same code over and over again- and in fact for > many to do so incompletely, omitting the dynamic lock support.
I agree, a fallback implementation would give OpenSSL a more robust interface, and prevent some code smell for implementors. Right now it seems that the chil plugin is the only place where dynamic locks are actually used, but I assume that will change in the future. It seems to me that a generally available set of fallback dynamic locking callbacks would be of interest to the library at large, not just to the chil plugin so I'd suggest putting those routines somewhere else, perhaps closer to crypto/cryptlib.c where the global function pointers are allocated? My direct (and driven by my affiliation) interest is to unbreak the breakage of the chil engine in the absence of dynamic locks, and to see that backported to 0.9.8. However, putting the fallback implementation in may be the kind of deeper surgery you don't want to backport... Can we start a two-pronged approach where we apply and backport my original openssl_chil_nolocks_donotbreak.patch and then look into the fallback routines? The former is entirely localized to the chil engine and does not stand in the way of the latter (since when that's done the engine will just find the callbacks in place). Thanks, S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
