On June 16, 2004 12:46 pm, Richard Levitte - VMS Whacker wrote:
> kstef> I think we can make do with a less involved fix, actually, by
> kstef> just backing out the conditional if the engine still _requires_
> kstef> its own copy of the libcrypto code, or, preferably, just
> kstef> linking to libcrypto dynamically if the earlier requirement no
> kstef> longer holds.  I just need an expert's best guess and I'll be
> kstef> out of your hair.
>
> Backing out is not an option.  The ENGINE_get_static_state() check is
> there for a very specific reason that hits most Unixly users, at least
> if the engine is linked with the exact dynamic library that loads it.
> Since that's a fairly plausible scenario, I think it would be a bad
> move not to make any checks of the sort.

Indeed. However one problem with merging ENGINE_get_static_state() to 
0.9.6-stable is that it requires a new exported API symbol in openssl. 
Specifically, building dynamic engines uses an engine.h macro that calls 
this (newly introduced) function, so we'd have to bump the magic version 
stuff to prevent weird linker freakouts and give more meaningful errors 
when the loading instance doesn't have that new function. I'm not against 
merging it, as such, but wanted to raise the issue.

The alternative is to make the check draconian so at least the bug 
disappears - ie. if the error callbacks in the engine lib's context don't 
match the callbacks in the crypto lib's context, don't try to alter them 
(it'll fail anyway), just refuse the load. This would probably break 
dynamic engine capability on one or two strange platforms I guess, but 
then again, how could they have been working in this form anyway? If the 
engine lib resolves all libcrypto dependencies against the loading 
instance, things are fine, always. If the engine lib has its own copies 
of everything or resolves against a different instance(/version) than the 
loading context, it won't work. I'm not sure we can fix this in a 
stable-branch-friendly way, as it necessarily requires an API change, 
because it deals with libraries people build *using* the API (ie. they 
build engine libs), and that in turn opens the interop questions stable 
branches normally don't raise.

Hmmm.

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]

Reply via email to