OpenSSL mailserver didn't like the attachment, see http://www.michaelboman.org/how-to/building-openssl-on-windows for the previous attached file.
Best regards Michael Boman On Mon, Mar 15, 2010 at 6:21 AM, Michael Boman <mich...@michaelboman.org>wrote: > Thanks for your input, clarifications inline: > > On Fri, Mar 12, 2010 at 12:04 AM, Dave Thompson < > dave.thomp...@princetonpayments.com> wrote: > >> -dev added, I think this is actually a bug >> >> > From: owner-openssl-us...@openssl.org On Behalf Of Michael Boman >> > Sent: Monday, 01 March, 2010 11:40 >> <re: crash in BIO_set_fp, on Windows, could it be faq#PROG2?> >> >> > I am using OpenSSL 0.9.8l from >> http://www.slproweb.com/products/Win32OpenSSL.html >> >> > I link to these libraries for debugging: >> > C:\OpenSSL\lib\VC\ssleay32MTd.lib >> > C:\OpenSSL\lib\VC\libeay32MTd.lib >> >> > And these ones for release: >> > C:\OpenSSL\lib\VC\ssleay32MT.lib >> > C:\OpenSSL\lib\VC\libeay32MT.lib >> >> > I compile the program using the /MT (Release) and /MTd (Debug) >> flag >> > under C/C++ -> Code Generation >> >> Aside: all 4 pairs of .lib's in lib\VC (and one in lib) are >> exportlibs for the one pair of DLL's, which are actually /MD >> but use the applink mechanism, as mentioned in the FAQ, to get >> the right CRT -- assuming the EXE correctly compiles applink.c, >> and the code you referenced does. >> >> So this "should" work. And using the corresponding files from >> my (DLL) build of 0.9.8m it sort of does (see below), but using >> the SL distro I also get a crash. Stepping in the debugger I see >> code in SL that is similar but not identical. It appears to be >> built with VC++08 or possibly later, in particular for MSVCR90, >> while I use (elderly but still functional) VC++6.0 and MSVCRT[d], >> and the exit 0xC0000417 occurs in MSVCR90 appparently below _setmode. >> You didn't say what version of VC++ (and CRT) you are using. >> > > I am using VC++ 2008 Express on Windows 7 (64-bit), compiling against > 0.9.8m (currently; OP was 0.9.8l). Up-to-date code is available at > http://code.google.com/p/sslscan-win together with required VC++ project > and solution files. > > As I mentioned above I am currently using 0.9.8m, which I have compiled > myself using the attached script (place it in OpenSSL source directory) > using the following syntax: vc_build.cmd -d -i > > I am now linking to following libs for both debug and release: > C:\OpenSSL\openssl-0.9.8m\lib\libeay32.lib > C:\OpenSSL\openssl-0.9.8m\lib\ssleay32.lib > > OpenSSL include files are being picked up > from C:\OpenSSL\openssl-0.9.8m\include and I am now printing > out OPENSSL_VERSION_TEXT to confirm what header files I was building > against. > > >> I believe this is a bug: >> >> bss_file.c file_ctrl() case for SET_FILE_PTR uses UP_fsetmode >> not UP_fsetmod so it doesn't uplink when it apparently should; >> instead uses direct _fileno and _setmode which faults in MSVCR90. >> On (old) VC++6.0/MSVCRT _fileno is inlined and works, and _setmode >> sets an error (EBADF) which is ignored, and the mode (bin/text) >> set by the app at fopen is apparently left intact (and works OK). >> >> Also looking in the same area: >> >> bss_file.c BIO_new_file() calls *ctrl BIO_C_SET_FILE_PTR with >> flags not including BIO_FP_TEXT, which sets binary even if the >> call said e.g. "w" or "wt"; on Windows this gives poor results >> if the output actually is text and needs \n=CRLF translation. >> Similarly BIO_{read,rw,write,append}_filename do SET_FILENAME >> with flags not containing TEXT. Explicitly calling BIO_ctrl >> SET_FILENAME with e.g. BIO_FP_WRITE|BIO_FP_TEXT does work. >> And BIO_new_fp() although prototyped as 'close_flag' actually >> honors TEXT as well, as documented. >> >> Some other things I noticed in working on this app: >> >> Personally I would do each formatting op once to a membio or >> string, and then duplicate the result to stdout and xmlOutput. >> That would also avoid this problem, since then the app wouldn't >> be using an fpbio for xmlOutput; everything else seems to work. >> >> And I wouldn't indent SOOOOO deeply. And I would handle long >> serials, as apps/x509.c does, since bigger than 32b are pretty >> common and (often spurious) negatives shouldn't be misleading. >> >> And officially WSAStartup should be once per process, >> although since about W2k as I recall repeats are benign. >> And unextended (insecure) client-initiated renegotiation is >> probably -- we hope! -- going to stop working soon. >> >> Logically I think it should work to compile the app /MD with a >> new(er) compiler that uses MSVCR90 and thus doesn't need uplink, >> or any supported mode(s) and static link (lib\VC\STATIC\various.lib) >> against a new-enough library to be compatible (old MSVCRT is not, >> it apparently doesn't have some _cookie stuff the SL build wants). >> But I'm not in a position to try those out for now. >> > > Thank you so much for the general feedback, it is much appreciated. I will > take note of the suggested improvements and work them in to the application. > > Best regards > Michael Boman > > -- > http://michaelboman.org - Security Blog & Wiki > -- http://michaelboman.org - Security Blog & Wiki
