> > No they can't. However, if CRLF are showing up in > them, it means you > have put it in there some way, perhaps from > transfering a file in > binary mode to it? > > Text mode vs. binary mode is tricky business... >
Hm. I guess what you are saying is that the function in question assumes that any non-binary input has its line-endings normalized to be LF only. It then converts all the LF-only line endings to CRLF. I think in our case we actually have some code that explicitly normalizes the line endings to CRLF _before_ passing it in. We "fixed" the problem in our case by changing our call to specify the "BINARY" flag, since we knew our line-endings were already normalized to CRLF. I guess the really confusing part of this is that the PKCS7 functions for verification seem to assume normalized CRLF line-endings in some places, but the signature creation functions seem to assume LF-only line-endings (at least that is what you seem to be saying). Anyway, I guess this is not a bug, if you assert that the input should be normalized to LF-only line-endings. I thought that the purpose of this bit of code was to normalize _either_ LF-only OR CRLF line-ending to CRLF, which it clearly does not do. BTW, if it is given CRLF, it does NOT convert them to CRCRLF in most cases, it leaves them as CRLF. Perhaps that was the source of my confusion... it handles CRLF line-endings "correctly" most of the time... but not if they fall on certain buffer-size boundaries. --Peter Lincroft __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
