Re: [openssl.org #1400] spurious CRs in S/MIME clearsigned mails
Roumen Petrov wrote: Bruno Kozlowski via RT wrote: [SNIP] The resulting mailfile has mixed EOLs: Most lines end in LF, but 3 lines end in CRLF: | $ cat -A mailfile | grep "\^M" | Content-Type: text/plain^M$ | ^M$ | some text^M$ I think that this is correct - EOL for emails(headers, empty line, body) is CRLF, but at moment I cannot point to RFC. > [SNIP] Roumen --- dear roumen the rfc you pointed them, are : rfc2045, rfc2311 , rfc3850(3854) regrads __ Shahin Khorasani PKI Dept. Sharif SecureWare Co. www.parssign.com __ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1400] spurious CRs in S/MIME clearsigned mails
Bruno Kozlowski via RT wrote: [SNIP] The resulting mailfile has mixed EOLs: Most lines end in LF, but 3 lines end in CRLF: | $ cat -A mailfile | grep "\^M" | Content-Type: text/plain^M$ | ^M$ | some text^M$ I think that this is correct - EOL for emails(headers, empty line, body) is CRLF, but at moment I cannot point to RFC. > [SNIP] Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AES endianness difference in 0.9.8d?
On Mon, 2 Oct 2006, Bruce Stephens wrote: > Bruce Stephens <[EMAIL PROTECTED]> writes: > > [...] > > > Ah, I see a problem. > > > > The SPARC one fails the AES-128-ECB(encrypt) test: > > OK, on another box (with more up to date compiler and OS patches) it > passes, so it's probably a toolchain problem. The working one probably has 120760-09, 121015-02, & 121017-04. (Sun Studio 11 patches) -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AES endianness difference in 0.9.8d?
Bruce Stephens <[EMAIL PROTECTED]> writes: [...] > Ah, I see a problem. > > The SPARC one fails the AES-128-ECB(encrypt) test: OK, on another box (with more up to date compiler and OS patches) it passes, so it's probably a toolchain problem. [...] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
AES endianness difference in 0.9.8d?
I build OpenSSL 0.9.8d on x86 GNU/Linux with gcc-4.1, and on SPARC Solaris with Sun Studio 11 cc. I get the following. On GNU/Linux: brs% ./openssl aes-128-cbc -in pca-cert.srl -k secret -a U2FsdGVkX1/4wyyZncUl/+DrVpt/HzuHZcO+reAKB/w= On Solaris: edmund% ./openssl aes-128-cbc -in pca-cert.srl -k secret -a U2FsdGVkX18WqqIezK7bLX5j4xu/zokPsZIUEzkdEy4= (This is with the pca-cert.srl file in apps.) Ah, I see a problem. The SPARC one fails the AES-128-ECB(encrypt) test: Testing cipher AES-128-ECB(encrypt) Key 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Plaintext 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff Ciphertext 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a Ciphertext mismatch Got 95 fa f4 7a 28 67 23 17 73 b1 28 aa ba e7 ef fc Expected 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a make[1]: *** [test_evp] Error 9 make[1]: Leaving directory `/dsk/edmund1/brs/openssl-0.9.8d/test' __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
need help with certs
I need help... if my spelling it's wrong, you'll understand, I'm from Argentina. I'm using SSL to create certificates and I've created my own CA, by stunneling connections between the server and the users we want to ensure safety and credibility. I used to have a problem with my CAcertificate 'cause it hasn't got the IP or the page's common name, so I created a new one, using the IP, if I use that new certificatein the stunnel in the server it throws this error; [error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned] The user trying to connect has a certificate trusted by the server, and his stunnel says: bad certificate. I don't undestand why it's this error for. I'll apprishiate any help.
Re: Openssl 0.9.8x on SCO Openserver 5
On 10/01/2006 13:42, Brad House wrote: > > >>Also, please check to make sure that gcc is properly installed. Other > >>platforms seem to have the same type of problem when the system > >>headers aren't properly fixed up by the installation process. > > > >SCO provides gcc as part of a package of precompiled GNU tools so I can > >only assume it's correct. It was possible to easily build gcc on > >earlier versions of Openserver but no longer. > > > > I'd strongly recommend not using SCO's version of GCC. I've had > numerous problems with it myself. On SCO OpenServer 5.0.6a (w/o > execution environment update), the latest release that will build > and work is GCC 3.3.1 with binutils 2.14. With 5.0.6a with > the execution environment update, you can use later releases, > but I think 3.3.6 is really as high as you might be able to > go reliably (I don't think the 4.x stuff will work). > > Running GCC 3.3.1 and binutils 2.14 I get no errors at all during > a make test, and even FIPS mode works. > > On SCO OpenServer 6, you must use SCO's native compiler, but because > of a bug in the compiler, FIPS mode won't work, but otherwise, I > haven't seen any major issues. What problems have you seen with the SCO provided GNU tools? -- Roger Cornelius[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Openssl 0.9.8x on SCO Openserver 5
On 10/01/2006 17:19, Tim Rice wrote: > On Sun, 1 Oct 2006, Roger Cornelius wrote: > > > On 09/30/2006 12:05, Tim Rice wrote: > > > On Fri, 29 Sep 2006, Roger Cornelius wrote: > > > > > > Native compiler works here (w/ the HACK mentioned above) but you > > > I just tried gcc. (don't need no-sha512 w/ gcc) > > > All tests pass > > > > Regardless of what I do, I'm unable to get past the core dumping sh512t > > test mentioned in my original message when building with gcc. How are > > you invoking config? Do you have MP5 installed? Are you using version > > 5.0.7Kj of the GNU dev tools that SCO provides? For what it's worth, I > > had this problem pre-MP5 and with the previous version of the gnu dev > > tools. > > Ethier "./config zlib" or "./config zlib-dynamic" works fine here > (w/ the HACK mentioned earlier). OK, I've tried that and just "./configure" with the same core dump in the sha512t test. Also tried removing all compiler optimization with the same result. > I'm still on MP4. I'll load MP5 when I get some free time. > I'm running the version of GNU dev tools in my media kit, 5.0.7g (gcc 2.95.3) > > Where did 5.0.7Kj come from? It's here: ftp://ftp.sco.com/pub/openserver5/opensrc/gnutools-5.0.7Kj I don't recall when I installed it, but the timestamps on the files are August 2003 and the only prerequisite is MP1, so it's been around for awhile. -- Roger Cornelius[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1400] spurious CRs in S/MIME clearsigned mails
Hello, On the Linux platform, OpenSSL generating an S/MIME clearsigned mail introduces spurious CRs at the end of some lines of the output. Depending on mail transport conditions, those CRs can break signature verification in MSOE on MS-Windows. Example: I want to clearsign "some text". Under Linux with OpenSSL 0.9.8d, I type: | $ echo "some text" > textfile | $ openssl smime -sign -text -signer ~/.smime/certificates/26f06522.0 \ | -inkey ~/.smime/keys/26f06522.0 < textfile > mailfile The resulting mailfile has mixed EOLs: Most lines end in LF, but 3 lines end in CRLF: | $ cat -A mailfile | grep "\^M" | Content-Type: text/plain^M$ | ^M$ | some text^M$ Those are exactly the 3 signed lines: It seems that EOL canonicalization somewhat leaked to the output mailfile. Note: If I drop -text option, and feed openssl with a prepared MIME part (mini-header, empty line, text), the same spurious CRs do appear. One problem is that saving a text file with CRLF on a LF platform is probably not really approriate. Mixed CRLF and LF is surely not. Bigger consequence: Depending on MTA/MDA/POP3 tools transporting the mail, those spurious CRs can be filtred-out or survive. Sending such mails to Windows platform happens to result in CRCRLF. And with such EOL, Outlook Express fails signature verification, claiming the message was falsified. If anything filtred-out the spurious CRs, verification succeeds. Problem seen on OpenSSL 0.9.8d and 0.9.7e. Seemingly 0.9.6 (unknown letter) had no problem. Bye!Bruno. -- /* Bruno Kozlowski <[EMAIL PROTECTED]> */ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
