openssl 0.9.6h - i
Hi, I've noticed this while reviewing diffs between 0.9.6h and 0.9.6i: --- openssl-0.9.6h/crypto/x509/x509_vfy.c Thu Nov 28 11:06:30 2002 +++ openssl-0.9.6i/crypto/x509/x509_vfy.c Tue Dec 10 11:28:16 2002 @@ -897,7 +897,7 @@ ctx-chain=NULL; } CRYPTO_free_ex_data(x509_store_ctx_method,ctx,(ctx-ex_data)); - OPENSSL_cleanse(ctx-ex_data,sizeof(CRYPTO_EX_DATA)); + memset(ctx-ex_data,0,sizeof(CRYPTO_EX_DATA)); } Is this change intentional, it appears to undo the change introduced between 0.9.6g and 0.9.6h? -- /sd __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #515] 0.9.7a
Hello, try ./config shared no-engine, then compile. Apache 1.3.27/mod_ssl crashes with segmentation fault. if i remove 'no-engine' - all ok, linux 2.4.19/gcc 2.95.3/glibc 2.1.3 --- WBR, Alexey. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #516] OpenSSL-0.9.7a on IA64 with Intel compiler
System: IA-64, SuSE SLES-8 Compiler: Intel(R) C++ Itanium(R) Compiler for Itanium(R)-based applications Version 7.0, Build 20021210 I've patched the Configure script by adding a new configuration, linux-ia64-ecc. It's based on the linux-ia64 configuration with the following changes: Compiler executable changed from gcc to ecc The Intel compiler is /opt/intel/compiler70/ia64/bin/ecc Deleted -fomit-frame-pointer option As far as I can tell from the documentation, the behavior specified by gcc's -fomit-frame-pointer option is the default behavior for ecc. Changed -O3 to -O2 Experiment shows that with -O3, make test fails with: test BN_sqr Square test failed! This seems to be an instance of the problem described at http://www.openssl.org/support/faq.html#BUILD11. I've provided a context diff for Configure as an attachment. Also, one of the compiler warnings points to a possible bug. The file crypto/mem_clr.c contains the following: cleanse_ctr += (17 + (unsigned char)((int)p 0xF)); where p is an unsigned char*. The cast of p to type int will lose significant bits, since int is 32 bits and pointers are 64 bits. I don't know of any symptoms of this bug; in particular, casting to unsigned long rather than int doesn't fix the BN_sqr problem. Please let me know if you need more information. -- Keith Thompson, San Diego Supercomputer Center, Camp X-Ray [EMAIL PROTECTED] http://www.sdsc.edu/~kst/ 858-822-0853 Fax: 858-822-5407 Schroedinger does Shakespeare: To be *and* not to be __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl 0.9.6h - i
In message [EMAIL PROTECTED] on Thu, 20 Feb 2003 10:06:55 +0300, Solar Designer [EMAIL PROTECTED] said: solar --- openssl-0.9.6h/crypto/x509/x509_vfy.c Thu Nov 28 11:06:30 2002 solar +++ openssl-0.9.6i/crypto/x509/x509_vfy.c Tue Dec 10 11:28:16 2002 solar @@ -897,7 +897,7 @@ solar ctx-chain=NULL; solar } solar CRYPTO_free_ex_data(x509_store_ctx_method,ctx,(ctx-ex_data)); solar - OPENSSL_cleanse(ctx-ex_data,sizeof(CRYPTO_EX_DATA)); solar + memset(ctx-ex_data,0,sizeof(CRYPTO_EX_DATA)); solar } solar solar Is this change intentional, it appears to undo the change introduced solar between 0.9.6g and 0.9.6h? Yes. ex_data is a pointer, need I say more? :-) -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #515] 0.9.7a
In message [EMAIL PROTECTED] on Thu, 20 Feb 2003 11:16:25 +0100 (MET), Alexey Semenov via RT [EMAIL PROTECTED] said: rt try ./config shared no-engine, then compile. rt Apache 1.3.27/mod_ssl crashes with segmentation fault. rt if i remove 'no-engine' - all ok, rt linux 2.4.19/gcc 2.95.3/glibc 2.1.3 It's possible mod_ssl expects the engine framework to be present, and is basically pissed off... Do you have any log to show us? Do you have the possibility to run under a debugger and get us a traceback? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #515] 0.9.7a
In message [EMAIL PROTECTED] on Thu, 20 Feb 2003 11:16:25 +0100 (MET), Alexey Semenov via RT [EMAIL PROTECTED] said: rt try ./config shared no-engine, then compile. rt Apache 1.3.27/mod_ssl crashes with segmentation fault. rt if i remove 'no-engine' - all ok, rt linux 2.4.19/gcc 2.95.3/glibc 2.1.3 It's possible mod_ssl expects the engine framework to be present, and is basically pissed off... Do you have any log to show us? Do you have the possibility to run under a debugger and get us a traceback? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #514] Bug in OpenSSL????
On Wed, Feb 19, 2003 at 06:10:13PM +0100, Ralph via RT wrote: on AIX (64bit) I noticed a major problem with non-blocking sockets. Methods SSL_connect(), SSL_read() and SSL_write() should return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete their tasks but the socket couldn't handle all the work. But instead, the methods return SSL_ERROR_SYSCALL when the underlying socket gave errno=EWOULDBLOCK or errno=EAGAIN (means: the application should retry with these functions if it has not been completed, yet) from their respective functions (read() and write()). For these specific system error numbers, the SSL functions should return SSL_ERROR_WANT_* return codes, shouldn't they? PS: However, on AIX 4.2 and earlier, this didn't seem to be a problem. Funny, isn't it? (But these versions are not supported by IBM anymore!) It's not SSL_connect() etc. that will return these error codes, it's SSL_get_error(). But probably you meant that, or you would not get SSL_ERROR_SYSCALL. Can you tell what is going on by looking at the definition of SSL_get_error (ssl/ssl_lib.c) and BIO_sock_should_retry and BIO_sock_non_fatal_error (crypto/bio/bss_bio.c)? You might want to add some debugging output in BIO_sock_non_fatal_error(). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #515] 0.9.7a
On Thu, 20 Feb 2003, Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Thu, 20 Feb 2003 11:16:25 +0100 (MET), Alexey Semenov via RT [EMAIL PROTECTED] said: rt try ./config shared no-engine, then compile. rt Apache 1.3.27/mod_ssl crashes with segmentation fault. rt if i remove 'no-engine' - all ok, rt linux 2.4.19/gcc 2.95.3/glibc 2.1.3 It's possible mod_ssl expects the engine framework to be present, and is basically pissed off... maybe, i just upgraded from 0.9.7 to 0.9.7a. Do you have any log to show us? Do you have the possibility to run under a debugger and get us a traceback? root@swaj: /usr/local/apache_ssl/bin#./httpd Segmentation fault root@swaj: /usr/local/apache_ssl/bin#ldd ./httpd libm.so.6 = /lib/libm.so.6 (0x4001c000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40039000) libdb.so.3 = /lib/libdb.so.3 (0x40067000) libssl.so.0.9.7 = /usr/local/lib/libssl.so.0.9.7 (0x400a1000) libcrypto.so.0.9.7 = /usr/local/lib/libcrypto.so.0.9.7 (0x400d1000) libc.so.6 = /lib/libc.so.6 (0x401ae000) libdl.so.2 = /lib/libdl.so.2 (0x402a3000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) root@swaj: /usr/local/apache_ssl/bin#gdb ./httpd GNU gdb 5.2 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...(no debugging symbols found)... (gdb) r Starting program: /opt/apache_ssl/bin/httpd (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x4013ec1d in EVP_DigestUpdate () from /usr/local/lib/libcrypto.so.0.9.7 (gdb) where #0 0x4013ec1d in EVP_DigestUpdate () from /usr/local/lib/libcrypto.so.0.9.7 #1 0xb9a4 in ?? () #2 0x40139975 in RAND_SSLeay () from /usr/local/lib/libcrypto.so.0.9.7 #3 0x08071215 in strcpy () at ../sysdeps/generic/strcpy.c:30 #4 0x08070ff0 in strcpy () at ../sysdeps/generic/strcpy.c:30 #5 0x0808ee54 in strcpy () at ../sysdeps/generic/strcpy.c:30 #6 0x0809a463 in strcpy () at ../sysdeps/generic/strcpy.c:30 #7 0x401c69cb in __libc_start_main (main=0x809a0b8 strcpy+314564, argc=1, argv=0xbcd4, init=0x804bf54 _init, fini=0x80d2890 _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbccc) at ../sysdeps/generic/libc-start.c:92 -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. --- WBR, Alexey. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl 0.9.6h - i
Sorry for following up on my own mail, but I just wanted to say that reverting the change now seems right to me (it's setting ex_data-sk to NULL, not zeroing out sensitive data). On Thu, Feb 20, 2003 at 10:06:55AM +0300, Solar Designer wrote: Hi, I've noticed this while reviewing diffs between 0.9.6h and 0.9.6i: --- openssl-0.9.6h/crypto/x509/x509_vfy.c Thu Nov 28 11:06:30 2002 +++ openssl-0.9.6i/crypto/x509/x509_vfy.c Tue Dec 10 11:28:16 2002 @@ -897,7 +897,7 @@ ctx-chain=NULL; } CRYPTO_free_ex_data(x509_store_ctx_method,ctx,(ctx-ex_data)); - OPENSSL_cleanse(ctx-ex_data,sizeof(CRYPTO_EX_DATA)); + memset(ctx-ex_data,0,sizeof(CRYPTO_EX_DATA)); } Is this change intentional, it appears to undo the change introduced between 0.9.6g and 0.9.6h? -- /sd __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #507] NULL _mod_exp functions can cause crash when verifying DSA with ubsec
[geoff - Sat Feb 15 22:50:51 2003]: [geoff - Sat Feb 15 21:48:27 2003]: I've attached a diff that I think addresses the problem but I'll need to consider the consequences a bit more in terms of how this could affect existing (and 3rd party and future) DSA implementations. Could you please try this out with your ubsec support and see if the handling of fallback to software is better (at least with respect to segfaults)? I will try it out. It will require me to update our app to 0.9.7 though which may take a little while (though it's something I want to do anyway). Thanks very much, -- Jonathan __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #507] NULL _mod_exp functions can cause crash when verifying DSA with ubsec
[guest - Thu Feb 20 19:00:47 2003]: The patch works, the app no longer crashes while verifying the DSA signature that it crashed on before. It took me a while to get my app running with 0.9.7a because I couldn't figure out why the ubsec code wasn't being built in -- I wasn't crashing when running without the patch as I expected. A call to ENGINE_load_builtin_engines() did the trick; I saw the crash; then did the patch and saw the crash go away. Yeah! -- Jonathan __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #517] Compiler warnings from crypto/pkcs12/p12_npas.c with HP ANSI comp iler
This isn't a big one, but the HP ANSI C (and the HP ANSI C++) compiler give
the following warnings when building crypto/pkcs12/p12_npas.c:
cc: warning 5004: Uninitialized variable pbe_iter in function
newpass_p12 (5004)
cc: warning 5004: Uninitialized variable pbe_saltlen in function
newpass_p12 (5004)
cc: warning 5004: Uninitialized variable pbe_nid in function newpass_p12
(5004)
This is easily addressed with the following one-line change:
$ diff -c p12_npas.c.orig p12_npas.c
*** p12_npas.c.orig Sat Dec 30 20:12:57 2000
--- p12_npas.c Thu Feb 20 17:12:51 2003
***
*** 107,113
{
STACK_OF(PKCS7) *asafes, *newsafes;
STACK_OF(PKCS12_SAFEBAG) *bags;
! int i, bagnid, pbe_nid, pbe_iter, pbe_saltlen;
PKCS7 *p7, *p7new;
ASN1_OCTET_STRING *p12_data_tmp = NULL, *macnew = NULL;
unsigned char mac[EVP_MAX_MD_SIZE];
--- 107,113
{
STACK_OF(PKCS7) *asafes, *newsafes;
STACK_OF(PKCS12_SAFEBAG) *bags;
! int i, bagnid, pbe_nid = 0, pbe_iter = 0, pbe_saltlen = 0;
PKCS7 *p7, *p7new;
ASN1_OCTET_STRING *p12_data_tmp = NULL, *macnew = NULL;
unsigned char mac[EVP_MAX_MD_SIZE];
I've been doing this for the past few 0.9.6* releases (and 0.9.7) without
introducing any problems, so I thought I'd pass it back to you.
Regards,
James
--
James A. Drenter
Planning, Architecture, and Technology Infrastructure Team
Hewlett-Packard Services Americas / Operations and I.T.
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
