On Monday 14 June 2004 10:54 am, Geoff Thorpe wrote:
> On June 14, 2004 10:20 am, Kevin Stefanik wrote:
> [snip]
>
> > #define IMPLEMENT_DYNAMIC_BIND_FN(fn) \
> > int bind_engine(ENGINE *e, const char *id, const dynamic_fns *fns) { \
> > if (ERR_get_implementation() != fns->err_fns) \
> > { \
> > if(!CRYPTO_set_mem_functions(fns->mem_fns.malloc_cb, \
> > fns->mem_fns.realloc_cb, fns->mem_fns.free_cb)) \
> > return 0; \
> > CRYPTO_set_locking_callback(fns->lock_fns.lock_locking_cb); \
> > CRYPTO_set_add_lock_callback(fns->lock_fns.lock_add_lock_cb); \
> >
> > CRYPTO_set_dynlock_create_callback(fns->lock_fns.dynlock_create_cb);
> > \ CRYPTO_set_dynlock_lock_callback(fns->lock_fns.dynlock_lock_cb); \
> > CRYPTO_set_dynlock_destroy_callback(fns->lock_fns.dynlock_destroy_cb);
> > \ if(!CRYPTO_set_ex_data_implementation(fns->ex_data_fns)) \
> > return 0; \
> > if(!ERR_set_implementation(fns->err_fns)) return 0; \
> > } \
> > if(!fn(e,id)) return 0; \
> > return 1; }
> >
> > If the library is statically compiled, then the ERR_get_implementation
> > will initialize the static err_fns to err_defaults. The
> > ERR_set_implementation will then report an error because that static
> > err_fns is not null.
>
> But ERR_set_implementation() should not be called because
> ERR_get_implementation() should equal fns->err_fns in the static case and
> so the code path should skip straight to the call to fn(). However ...
>
That fns is being handed in by the openssl application, right? So the
fns->err_fns is from the openssl context. But this macro is part of the
engine, so the ERR_get_implementation will return the engine's err_fns, no?
I thought that those set_..._callback functions were only called for the
staticly linked library. I recall that the CRYPTO_set_mem_functions kicked
errors if the library was shared.
> > I think this effectively makes statically linked engines impossible -
> > which I really don't mind. Can we just always use shared engines as of
> > 0.9.7d?
>
> Actually it seems to me to be the other way around. It appears that this
> has probably broken the use of shared-lib engines on any platforms where
> the loaded shared-lib has its own copy of libcrypto functions/state. What
> exactly have you been seeing to make you believe it's the other way
> round?
Several users of the opensc engine have told me that the statically linked
engine kicks:
engine routines:DYNAMIC_LOAD:init//failed:eng_dyn.c:433:
While the dynamically linked version has worked. I haven't yet reproduced
myself.
>
> Thanks for the head's up, we'll need to look into this - but I'd also like
> to know why you're seeing (or think you're seeing) errors in the
> statically-compiled case? Can you alter the macro to display the values
> of ERR_get_implementation() and fns->err_fns before that if(){} branch,
> as those values should match in the static case.
It'll take me some time to get a proper setup, but maybe Zoltan can?
Thanks for the quick attention,
Kevin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
