[openssl-dev] Upcoming build system change

[Richard Levitte]

Corinna Vinschen <vinschen at redhat.com> skrev: (24 januari 2016 13:19:00 CET)
>On Jan 23 22:12, Richard Levitte wrote:
>> In message <20160123210116.GB13479 at calimero.vinschen.de> on Sat, 23
>Jan 2016 22:01:16 +0100, Corinna Vinschen <vinschen at redhat.com> said:
>> 
>> vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
>> vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna
>Vinschen wrote:
>> vinschen> > > 
>> vinschen> > > Last but not least, we have another problem with
>enginesdir.  To allow a
>> vinschen> > > rolling release cycle, we have to support multiple
>versions of openssl
>> vinschen> > > in parallel.  The problem here is that the enginesdir
>needs to be
>> vinschen> > > versioned to allow per-openssl version engines.  The
>build scripts don't
>> vinschen> > > allow for this.  Right now we're using a patch as the
>below one to tweak
>> vinschen> > > the configury to allow specifying the engines dir
>during build time.
>> vinschen> > > Would it hurt terribly to include something like the
>below patch?
>> vinschen> > 
>> vinschen> > In general, I would like to have a directory for the
>engines that
>> vinschen> > relates to OSSL_DYNAMIC_OLDEST.
>> vinschen> 
>> vinschen> That probably won't work for Cygwin.  The engines are
>linked against the
>> vinschen> versioned DLLs of the OpenSSL version they have been built
>for,  Even
>> vinschen> assuming binary compatibility, an engine linked against
>openssl-1.0 will
>> vinschen> pull in openssl-1.0 DLLs, even when loaded from
>openssl-1.1.  We have to
>> vinschen> keep the engines separate.
>> 
>> 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? 

> 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. 

>
>
>Corinna
>
>
>(*) On Windows (but NOT Cygwin): LoadLibrary/GetProcAddress.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.