Brad House wrote: > Are you then using VC++ to generate the final DLL which you use > with your multithreaded application?
Correct. > If so, do you receive crashes regardless of if you're in FIPS mode > at the time or not? My guess is yes. I haven't tried it, but I would anticipate that the object code with the problematic static variables is used in both FIPS and non-FIPS modes. For example, p_verify.c appears to be one of those files that does not reside within the fips subdirectory, but is sequestered in the object module. I would be surprised if there was a separate copy of that object code for non-FIPS mode use. At one point I had a working FIPS-enabled build with debug symbols, but for some reason, my more recent attempts fail the runtime FIPS canister fingerprint test. Hence my inability to directly verify the above. > The whole point to the validation was that it is a source-level validation > which is totally independent of the OS. This is my understanding as well; as long as the Windows build is done in accordance with the Security Policy (which the instructions for Windows builds in the Users Guide are asserted to be), the result is validated. That is certainly what the Security Policy, Users Guide, and various other online sources (e.g. http://oss-institute.org/fips-faq.html#a9) lead one to believe. > So far no one has been able to have a technical discussion on the issue > which was reported, instead everyone is focusing on totally irrelevant > issues. I'm not sure why, but it doesn't seem particularly > productive. Agreed. The suggestion of modifying OpenSSL so that Windows builds don't require OPENSSL_SYS_MSDOS to be defined certainly seems like the best long-term solution, but doesn't help anyone trying to get 1.1.1 working on Windows today. John ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
