I just realized that we may not have been discussing the same issue. When I
was referring to dynamically or statically linked engines, I was referring to
how the engines were linked to libcrypto. In all cases, we're discussing a
dynamic engine contained in a shared library, so I think we agree on the
problem.
Sorry for the confusion,
Kevin
On Monday 14 June 2004 11:08 am, Kevin Stefanik wrote:
> 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]
