[openssl-dev] Upcoming build system change

[Richard Levitte]

On January 24, 2016 3:52:19 PM GMT+01:00, Corinna Vinschen <vinschen at redhat.com> wrote:
>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?

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

-- 
levitte at openssl.org