On 30-09-2010 17:34, Carter Browne wrote:
I would like to request that when changes are made to verification items such
as the hash code for certification validation that the Windows operation be
taken into consideration. DLLs are a global resource in Windows and are
identified by name. Once a DLL is loaded, any other request of that same DLL
name is routed to that DLL. Openssl is a great product and it has wide use. On
my development system I have different SSLEAY32.DLLs in packages from Apple,
Watchguard, Dell, Sony, Stunnel, and TrendMicro. The selection of the DLL that
gets loaded happens at start-up time and to the best of my knowledge is a side
effect of the services that get loaded and the order that Windows loads them.
Thus, the proper hash code name for a certificate in the certificate directory
becomes a function of load order. Windows does not have the easy name link
facility that most operating systems do which adds to the difficulty. While it
would be good to make sure that the most current version of SSLEAY32 is loaded,
it is much worse to have a total failure of the verification process if the
wrong one is loaded. Version incompatibilities of DLLs (known as DLL in the
Windows world) can take some time to identify. If possible, it would be greatly
appreciated if such incompatibilities could be avoided except for necessary
functional or security reasons.
Sorry, you are factually wrong here. What you write is only true for
the old 16 bit Windows (Windows 3.11 and older), not for any 32 bit or
64 bit Windows versions. For 32 bit Windows versions, DLL loading and
DLL name clashes occur only if two DLLs with the same name (such as two
SSLEAY32.DLL versions) are loaded into the same process. This will
typically only happen in 4 cases:
A) The program in that process was built using multiple OpenSSL versions
at the same time, this really should not happen with professional practices.
B) The program uses plugins or 3rd party components that are each linked
to a different SSLEAY32.DLL version. For this reason plugins
should ALWAYS be compiled against the SSLEAY32.DLL of the containing
application (if any), or link statically against OpenSSL. This advice
applies to any platform that does not use "versioned so-names".
C) Some mindless supplier of system addons such as antivirus software
made the mistake of linking to SSLEAY32.DLL in a component which is
injected into 3rd party processes all over the system. Such injected
components (DLLs) must be linked statically to any common non-Microsoft
libraries (and some Microsoft libraries too!) to avoid DLL clashes.
D) Someone installed SSLEAY32.DLL into one of the system-wide locations
(%windir% %windir%\System32 etc., similar to /lib and /usr/lib on UNIX).
This will conflict with any program needing a different version.
P.S.
In Windows XP, Microsoft introduced their own badly designed idea of
"versioned so-names" in the form of so-called "Assemblies". Unless
you are writing .NET code, you should really avoid that nonsense.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
