On Thu October 2 2008, Thomas J. Hruska wrote: > Thomas J. Hruska wrote: > > Feel free to follow along with this e-mail: > > > > http://www.slproweb.com/download/bad_openssl.zip > > > > I just zipped up the contents of the 'out32dll' directory. What you see > > is what I've got in my out32dll directory. And now onto the main part > > of the e-mail. > > > > > > This is my first time building FIPS but given that I generally know how > > to build pretty much anything OpenSSL, it probably isn't my fault > > (famous last words). The build process works fine up to this point: > > > > out32dll\fips_premain_dso.exe out32dll\libeay32.dll > > 2348:error:25078067:DSO support routines:WIN32_LOAD:could not load the > > shared library:.\crypto\dso\dso_win32.c:147:filename(out32dll\libeay32.dll) > > 2348:error:25070067:DSO support routines:DSO_load:could not load the > > shared library:.\crypto\dso\dso_lib.c:244: > > Get hash failure at util\fipslink.pl line 48. > > NMAKE : fatal error U1077: 'C:\Perl\bin\perl.EXE' : return code '0x1' > > Stop. > > > > > > Looking at fipslink.pl, it looks like the first line displayed is the > > executable/command run. Running that command directly, I get the two > > error messages after Windows displays this message box: > > > > "Bad Image" > > "The application or DLL C:\[path]\openssl-0.9.7m\out32dll\libeay32.dll > > is not a valid Windows image. Please check this against your > > installation diskette." > > > > > > So, it is finding the DLL but refusing to load. It could be the fixed > > address issue and wanting to relocate, but using one of the tools I use, > > it is clear to me that something seriously hosed the file up somewhere > > along the line in the build process. There is a relocation table data > > directory entry but no relocation table (appears to be intentional file > > truncation) and a missing section. One of the tools I've used for years > > without problems is balking at the file. I'm not surprised that Windows > > isn't loading the DLL. > > > > > > VC++ 2008 Professional (not SP1) > > Windows XP SP2 > > FIPS 1.1.2 w/ OpenSSL 0.9.7m > > fipscanister.o and other files reside on a CD-R (drive e:) built against > > the MSYS instructions in the User Guide for 1.1.1. > > perl Configure VC-WIN32 fips --with-fipslibdir=e:/ > > Beyond that, regular build process using NASM (latest). > > Fresh 0.9.7m and FIPS 1.1.2 files, cross-referenced against the MD5 and > > SHA-1 hashes on the site (which, BTW, the website links are broken, I > > had to go through FTP). > > > > > > Additional tests: > > > > While paused at the message box, I ran a little tool I wrote many years > > ago: > > > > Process ID: 2904 > > Module ID = 00400000, Module Name = FIPS_PREMAIN_DSO.EXE, Module > > Filename = > > c:\cfiles\projects\winssl\openssl-0.9.7m\out32dll\FIPS_PREMAIN_DSO.EXE > > Module ID = 7C900000, Module Name = ntdll.dll, Module Filename = > > C:\WINDOWS\system32\ntdll.dll > > Module ID = 7C800000, Module Name = kernel32.dll, Module Filename = > > C:\WINDOWS\system32\kernel32.dll > > Module ID = 08370000, Module Name = depends.dll, Module Filename = > > C:\PROGRA~1\MIAF9D~1\Common\Tools\depends.dll > > Module ID = 77DD0000, Module Name = ADVAPI32.dll, Module Filename = > > C:\WINDOWS\system32\ADVAPI32.dll > > Module ID = 77E70000, Module Name = RPCRT4.dll, Module Filename = > > C:\WINDOWS\system32\RPCRT4.dll > > Module ID = 77FE0000, Module Name = Secur32.dll, Module Filename = > > C:\WINDOWS\system32\Secur32.dll > > Module ID = 71AD0000, Module Name = WSOCK32.dll, Module Filename = > > C:\WINDOWS\system32\WSOCK32.dll > > Module ID = 71AB0000, Module Name = WS2_32.dll, Module Filename = > > C:\WINDOWS\system32\WS2_32.dll > > Module ID = 77C10000, Module Name = msvcrt.dll, Module Filename = > > C:\WINDOWS\system32\msvcrt.dll > > Module ID = 71AA0000, Module Name = WS2HELP.dll, Module Filename = > > C:\WINDOWS\system32\WS2HELP.dll > > Module ID = 7E410000, Module Name = USER32.dll, Module Filename = > > C:\WINDOWS\system32\USER32.dll > > Module ID = 77F10000, Module Name = GDI32.dll, Module Filename = > > C:\WINDOWS\system32\GDI32.dll > > Module ID = 78520000, Module Name = MSVCR90.dll, Module Filename = > > C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.dll > > > > > > Module ID = 76390000, Module Name = IMM32.DLL, Module Filename = > > C:\WINDOWS\system32\IMM32.DLL > > Module ID = 629C0000, Module Name = LPK.DLL, Module Filename = > > C:\WINDOWS\system32\LPK.DLL > > Module ID = 74D90000, Module Name = USP10.dll, Module Filename = > > C:\WINDOWS\system32\USP10.dll > > > > > > No apparent base address conflicts with the loader and libeay32.dll > > (preferred base at the default 0x0FB00000). > > > > > > Dependency Walker was running the app. at the time and showed the > > following output: > > > > LoadLibraryA("out32dll\libeay32.dll") called from "FIPS_PREMAIN_DSO.EXE" > > at address 0x00412540. > > LoadLibraryA("out32dll\libeay32.dll") returned NULL. Error: %1 is not a > > valid Win32 application (193). > > Needless to say, given the lack of response and further web searching > reveals issues with older VC++ linkers core dumping(?) against the > latest MinGW and I've already put forth 30+ hours (not counting the > preparation time of several months!), two CD-Rs, and who knows how much > money into an attempted production of a default OpenSSL FIPS 140-2 > compliant binary build for Windows (complete with fancy installer), I'm > going to simply hold off until 1.2.0 becomes available and then try > again at that time. Mixing together binaries from two totally different > compilers is not only a bad idea, it is a horrifically terrible idea. > The fact that this supposedly works at all for some people is a miracle. > > Supposedly, from what I've read, 1.2.0 doesn't require mixing compilers. > That should significantly clean things up. Assuming, of course, "not > mixing compilers" allows the use of VC++. If I have to use MinGW, I > will be very annoyed. I'm also hoping I can compile against 0.9.8x > instead of 0.9.7m. > > Case closed. For the time being. I'm all OpenSSL'ed out. >
1.1.0 does not build shared. Build static or wait for 1.2.0 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
