[openssl-dev] Upcoming build system change

[Corinna Vinschen]

On Jan 24 14:41, Richard Levitte wrote:
> Corinna Vinschen <vinschen at redhat.com> skrev: (24 januari 2016 13:19:00 CET)
> >On Jan 23 22:12, Richard Levitte wrote:
> >> This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
> >> around it that's meant to permit EXACTLY that kind of mixture.  It's
> >> in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
> >> not doing enough, and figuring out what else it needs to do is a
> >> venture I think is worth spending some time on.
> >
> >The problem here is Windows and how DLL dependencies are resolved.
> >We're using versioned DLLs, e.g.
> >
> >  /usr/bin/cygcrypto-0.9.8.dll
> >  /usr/bin/cygcrypto-1.0.0.dll
> >  /usr/bin/cygcrypto-1.1.dll
> >
> >When building engines, the engines are shared libs linking against the
> >crypto DLL.  This creates a hard dependency to the DLL the engine has
> >been linked against.  So, consider using an application linked against
> >cygcrypto-1.1.dll.  It loads an engine built with and thus linked
> >against cygcrypto-1.0.0.dll.  While the application will use functions
> >from cygcrypto-1.1.dll, the engine will use functions from
> >cygcrypto-1.0.0.dll.
> 
> Yes, exactly. The way the engine API was designed from the start, that
> exact situation is meant to be supported. However, it's been long
> since I tested that aspect, so I can't personally tell if there's a
> bit of rot in there. That's certainly worth investigating... 
> 
> > Hilarity ensues.
> 
> Ok, so, a bit of rot or something other I fail to think of. Do you
> have details you'd like to share? 

No, that was only an attempt at humor.  I don't know either if that
works as desired...

> > Unless cygcrypto-1.0.0.dll has
> >been deprecated and removed.  In which case loading the engine fails.
> >
> >To decouple an engine from a DLL version, what we would have to do is
> >to change the engines not to link against libcrypto, but rather to load
> >*all* functions dynamically at runtime (dlload/dlsym(*)).  Only this
> >would allow to decouple the engines from a specific versioned DLL.
> 
> The decoupling of versions is supposed to be between the loading
> application and the loaded engine, not between them and the libcrypto
> versions they each use.

Hmm, ok.  I thought that it's not desired to run an application with one
crypto lib and the engine with another.  I can't exactly judge the
implications, but that sounds like it could result in problems, not only
on Cygwin, FWIW.  Is there any shared data between the calling crypto
lib and the engine?  What if the idea how to handle this shared data is
different between the crypto lib *calling* the engine and the crypto lib
*called* by the engine?

Still, the immediate problem is that a rolling release distro has to
keep two sets of engines depending on the OpenSSL release to support
existing packages until they have been rebuilt.  The other issues
is stuff you can judge much better than me,


Thanks,
Corinna
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160124/a94cac1f/attachment.sig>