>>>>> On Thu, 9 Aug 2007 16:09:14 -0700, John Firebaugh said: > > Following the Windows build instructions in the OpenSSL FIPS Users Guide > (using MinGW and MSYS) results in OpenSSL libraries that may crash if > used in a multithreaded program. > > The problem is due to the definition of MS_STATIC in e_os.h: > > #if defined(OPENSSL_SYS_MSDOS) && !defined(OPENSSL_SYSNAME_WIN32) > # define MS_STATIC static > #else > # define MS_STATIC > #endif > > When building with MinGW, OPENSSL_SYS_MSDOS is defined, and > OPENSSL_SYSNAME_WIN32 is not defined (instead OPENSSL_SYSNAME_MINGW32 is > defined). This results in key variables declared using MS_STATIC > vulnerable to race conditions. See for example p_verify.c line 71. > > As I understand it, I cannot modify the source or build sequence for the > FIPS Object Module, in which reside these problematic static variables, > without invalidating the 140-2 certification. This rather limits my > options for working around this bug. > > One option would be to serialize any and all calls to OpenSSL functions > with a global mutex. Needless to say, this would be a very painful and > expensive solution for any program that makes extensive use of OpenSSL > APIs or relies on parallelization for performance. > > A second option would be to create a wrapper gcc executable that adds > '-DOPENSSL_SYSNAME_WIN32' to the command line before passing it on to > the real gcc. While this seems not to violate the letter of the Security > Policy, it certainly seems shady. > > Anyone got a better idea?
Fix OpenSSL so that Windows builds don't require OPENSSL_SYS_MSDOS to be defined? __Martin ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
