[stunnel-users] Stunnel and DLL Hell

Sat Oct 2 16:08:04 CEST 2010

Hello,
I am not sure that static linking should be the good solution to this 
problem.
Having many software linked statically to different versions of the same 
library
could lead to other  problems (if they are interacting).
At least, with a few search on the system and trivial properties check, 
it is "easy" to have
a clear sight of the situation of your platform.

 From an integrator point of view, I agree anyway that it is useful 1/ 
to KNOW what version
of the library has been used at compile time (and is thus expected at 
exec time), 2/ to have the means to know what versions are available on 
the system,
and 3/ to have the mean to CHOSE what version to use at execution time.

Stunnel is involved only in the first point.

All this 3 questions have trivial answers :
1/- See log of stunnel to know the library version used at compile time
See also the changelog page to have this info : 
http://stunnel.mirt.net/?page=ChangeLog_sdf

2/ Windows search is now a mess but anyway finding some files is "possible".
More usefully, "msinfo32", in the "Loaded Modules" list, will show you 
each copy of a library that are loaded into the system,
but unfortunately not giving the loading program.

More simply : cd c:\ and then dir /a /b /s libeay32.dll will give you 
rapidly the different locations of the file you are searching for.

Some more tips and tools here : "Escape from DLL Hell with Custom 
Debugging and Instrumentation Tools and Utilities"
http://msdn.microsoft.com/en-us/magazine/bb985842.aspx

3/ Yes you have the choice :
by either having only one version of the dll on your system (typically 
in c:\windows), thus deleting all the others,
OR by having a copy of the desired dll in the same folder as each 
executable of interest.
The latter is done preferably, at least because some programs require a 
specific version, just because they have been validated vs that version 
(ie Quality Assurance reason):
This is WHY you have so many copies of the same lib on your system...
See more explanations here : Dynamic-Link Library Search Order
http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx

I recognize that my suggestions place the responsibility of dll 
consistency on the admin
of the platform, instead of on the "installer" provider that 
could/should check and warns about potential conflict at install time.

Finally, I do not think that the problem is "dynamic linking" in itself, 
but just "proper checking" or "proper location" at install time, and 
"proper administration"
of the software environment.
And just because of the fact that some versions of a software has been 
validated with a specific version of the dll,
it is almost mandatory that each sw places a copy of its critical dll in 
its own directory.

This is what is done by stunnel on win32, so there MUST not be any dll 
problem with it.
Other examples : PostgresQL, OpenOffice 3 and Apple iTunes all install 
their own copy of ssleay32.dll in their own directory.

If there is problem, it comes from installers that install "their 
version of some" dll directly in c:\windows (something that MS products 
are well known to do),
and/or by dll that break their interface or implementation from version 
to version (such dll should not be installed in common locations, of 
course).

Pierre Delaage

Le 30/09/2010 15:33, Carter Browne a écrit :
>   I just had an upgrade issue going from stunnel 4.32 (using the openssl 0.9.8x
> libraries) and stunnel 4.34 (using the openssl 1.0.0x libraries).  I'm using the
> CAPATH option and verify = 2 to verify connections.  The openssl group changed
> the hash algorithm between 0.9.8 and 1.0.0 so that the certificates have to have
> a different name (this is a Windows installation, so no linked names).  When I
> initially converted I has two copies of the names, one using the old hash and
> one using the new hash and everything worked perfectly.  However, after cleaned
> up the directories and removed the old hash names, things began to fail.
> Eventually I could not make any connections to the system running stunnel 4.34.
> Eventually, it occurred to me to check for multiple versions of the SSLEAY32.DLL
> and the system and there were a number of copies.  For whatever reason, the
> 0.9.8x version got loaded first and so the 1.0.0x hash names were not recognized.
>
> This explanation is a long winded request for having the option of having a
> statically linked version of stunnel for Windows.  I have about 10 systems
> running stunnel 4.34 and all but this one worked properly.  However, having the
> vagaries of which version of SSLEAY32 gets loaded by Windows first determining
> the correct operation of the system is an uncertainty that it would be very good
> to live without.
>
> Thanks for the consideration.
>
> Carter
>
> Carter Browne
> CBCS
> cbrowne at cbcs-usa.com
> 781-721-2890
>
>
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at mirt.net
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users
>    