On January 24, 2016 3:52:19 PM GMT+01:00, Corinna Vinschen <[email protected]> wrote: >On Jan 24 14:41, Richard Levitte wrote: >> Corinna Vinschen <[email protected]> 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?
They aren't supposed to share data, except for a few things, such as the heap. That's why heap handling hooks are passed when binding an engine, among a few other things... >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 > > >------------------------------------------------------------------------ > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- [email protected] _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
