In message <[EMAIL PROTECTED]> on Wed, 16 Jun 2004 19:27:27 -0400, Geoff Thorpe <[EMAIL PROTECTED]> said:
geoff> On June 16, 2004 12:46 pm, Richard Levitte - VMS Whacker wrote: geoff> > kstef> I think we can make do with a less involved fix, actually, by geoff> > kstef> just backing out the conditional if the engine still _requires_ geoff> > kstef> its own copy of the libcrypto code, or, preferably, just geoff> > kstef> linking to libcrypto dynamically if the earlier requirement no geoff> > kstef> longer holds. I just need an expert's best guess and I'll be geoff> > kstef> out of your hair. geoff> > geoff> > Backing out is not an option. The ENGINE_get_static_state() check is geoff> > there for a very specific reason that hits most Unixly users, at least geoff> > if the engine is linked with the exact dynamic library that loads it. geoff> > Since that's a fairly plausible scenario, I think it would be a bad geoff> > move not to make any checks of the sort. geoff> geoff> Indeed. However one problem with merging geoff> ENGINE_get_static_state() to 0.9.6-stable is that it requires a geoff> new exported API symbol in openssl. Well, I don't see that as a problem, since we don't have support for dynamic engines *at* *all* in 0.9.6... I assume you really meant to say 0.9.7-stable, and I see that as less of a problem on a general level, since there's no newer OpenSSL version than that. geoff> Specifically, building dynamic engines uses an engine.h macro geoff> that calls this (newly introduced) function, so we'd have to geoff> bump the magic version stuff to prevent weird linker freakouts geoff> and give more meaningful errors when the loading instance geoff> doesn't have that new function. I'm not against merging it, as geoff> such, but wanted to raise the issue. We *could* check if the magic version is the former level, and then not check at all (i.e. have some backward compatibility cruft), but if it's the newer level, we call ENGINE_get_static_state(). Of course, that means we need to keep two variants of struct st_dynamic_fns and do a bit of casting magic... geoff> The alternative is to make the check draconian so at least the geoff> bug disappears - ie. if the error callbacks in the engine lib's geoff> context don't match the callbacks in the crypto lib's context, geoff> don't try to alter them (it'll fail anyway), just refuse the geoff> load. This would probably break dynamic engine capability on geoff> one or two strange platforms I guess, but then again, how could geoff> they have been working in this form anyway? True, they probably worked better before I use ERR_get_implementation() to check against fns->err_fns. At the time I made that change, I didn't test on VMS for some reason, or I would have caught it at that time... ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsv�gen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See <http://www.stacken.kth.se/~levitte/mail/> for more info. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
