[openssl.org #486] ocsp.c make_ocsp_response() fix
The handling of the thisupd and nextupd pointers in make_ocsp_response() is incorrect. The pointers should be the first parameter of x509_gmtime_adj(), rather than the return value. I've attached a patch that fixes this. -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #486] ocsp.c make_ocsp_response() fix
Stephen Henson via RT wrote: However a bug was introduced into 0.9.7 ASN1_TIME_to_generalizedtime() which causes problems in this conversion. This change would work around the problem without addressing the underlying cause. Since the ASN1_TIME_to_generalizedtime() bug has now been fixed in 0.9.7-stable I suggest the OP checks the latest stable snapshot. Steve. Thanks for pointing this out. Indeed, patching in the asn1 changes from the latest snapshot fixes the problems I was seeing. And sorry, I should have pointed out from the beginning that it was 0.9.7 release that I was using. Thanks! -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #486] ocsp.c make_ocsp_response() fix
Stephen Henson via RT wrote: However a bug was introduced into 0.9.7 ASN1_TIME_to_generalizedtime() which causes problems in this conversion. This change would work around the problem without addressing the underlying cause. Since the ASN1_TIME_to_generalizedtime() bug has now been fixed in 0.9.7-stable I suggest the OP checks the latest stable snapshot. Steve. Thanks for pointing this out. Indeed, patching in the asn1 changes from the latest snapshot fixes the problems I was seeing. And sorry, I should have pointed out from the beginning that it was 0.9.7 release that I was using. Thanks! -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ocsp.c make_ocsp_response() fix
The handling of the thisupd and nextupd pointers in make_ocsp_response() is incorrect. The pointers should be the first parameter of x509_gmtime_adj(), rather than the return value. I've attached a patch that fixes this. -John --- ../../../orig/openssl-0.9.7/apps/ocsp.c 2002-12-03 08:34:23.0 -0800 +++ ocsp.c 2003-01-29 19:23:46.0 -0800 @@ -1043,9 +1043,11 @@ ca_id = OCSP_cert_to_id(EVP_sha1(), NULL, ca); bs = OCSP_BASICRESP_new(); - thisupd = X509_gmtime_adj(NULL, 0); + thisupd = ASN1_GENERALIZEDTIME_new(); + nextupd = ASN1_GENERALIZEDTIME_new(); + X509_gmtime_adj(thisupd, 0); if (ndays != -1) - nextupd = X509_gmtime_adj(NULL, nmin * 60 + ndays * 3600 * 24 ); + X509_gmtime_adj(nextupd, nmin * 60 + ndays * 3600 * 24 ); /* Examine each certificate id in the request */ for (i = 0; i id_count; i++)
Re: [openssl.org #434] duplicate execution of callback with non-blockingSSL_accept
Lutz Jaenicke via RT wrote: [[EMAIL PROTECTED] - Fri Jan 3 08:21:38 2003]: When a non-blocking SSL_accept() returns -1 with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE set, the appropriate thing to do is to call SSL_accept() again. This is fine, but the current state machine in ssl3_accept() doesn't seem to keep track of the fact that the callback may have succeeded already, causing the callback to be called again when SSL_accept() is retried. Is there some way around this that I'm missing? If not, wouldn't it be desirable to add something like this to the state machine in ssl3_accept()? I'm sure there are some cases where the callback should be called again (renegotiations, for example). Any ideas? You are talking of the verify callback? Yes, the client verify_callback. Thanks, -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
duplicate execution of callback with non-blocking SSL_accept
When a non-blocking SSL_accept() returns -1 with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE set, the appropriate thing to do is to call SSL_accept() again. This is fine, but the current state machine in ssl3_accept() doesn't seem to keep track of the fact that the callback may have succeeded already, causing the callback to be called again when SSL_accept() is retried. Is there some way around this that I'm missing? If not, wouldn't it be desirable to add something like this to the state machine in ssl3_accept()? I'm sure there are some cases where the callback should be called again (renegotiations, for example). Any ideas? -John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
hash function slowdown in 0.9.7?
Title: hash function slowdown in 0.9.7? Has anyone else noticed a considerable decrease in performance of md5 and sha1 from 0.9.6* to 0.9.7-beta*? It doesn't seem so bad for large data sizes, but it's particularly bad for data sizes less than 1024 bytes. I've found consistent results on different operating systems and processors. Here are my results of 'openssl speed md5 sha1' for 0.9.6g and 0.9.7beta3, running RedHat7.3 on a PIII-933: OpenSSL 0.9.6g [engine] 9 Aug 2002 built on: Mon Sep 9 11:41:47 PDT 2002 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM The 'numbers' are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md5 9735.21k 52952.34k 103338.58k 134945.71k 154970.79k sha1 6202.44k 30235.64k 54472.18k 68353.02k 73571.83k OpenSSL 0.9.7-beta3 30 Jul 2002 built on: Mon Sep 9 14:02:53 PDT 2002 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=pentium -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md5 9167.94k 29791.80k 76580.05k 122172.19k 147694.36k sha1 8264.75k 23119.26k 47949.99k 65059.75k 73067.71k -John
