Re: Crash in openSSL 1.0.1g

Update : Crashes are seen only on MAC OS X and not seen on windows. Thanks & Regards, -NK From: Cisco Employee mailto:navne...@cisco.com>> Reply-To: "openssl-dev@openssl.org" mailto:openssl-dev@openssl.org>> Date: Tuesday, 10 June 2014 11:20 AM To: "openssl-dev@o

Crash in openSSL 1.0.1g

Hello Team, We have recently done the upgrade to openSSL version 1.0.1g and facing many crashes in below code path. Crashes are seen consistently. Any pointer on what went wrong will be really helpful. Thanks for your time !! ==Crash stack trace= (lldb) bt * thread #30: tid = 0x

[openssl.org #3394] Suggested patch for null pointer errors

Hi, This is the follow-up patch suggestion for [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors, as requested. After running parfait on 1.0.1h, I have removed the first part (uninitialized memory error.) This is the patch for the other two files: 2

Re: Locking inefficiency

Hey Bodo, On Mon, Jun 9, 2014 at 3:15 PM, Bodo Moeller wrote: > Geoffrey Thorpe : > > First, you're right, pthreads_locking_callback() is collapsing everything >> to a mutex. >> > > I was well aware of this and thought we did this for compatibility reasons > (because I couldn't think of any othe

Re: [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors

Hi Tim, Thanks for your feedback! On 06/ 7/14 03:01 PM, Tim Hudson via RT wrote: On 7/06/2014 7:10 PM, Jenny Yung via RT wrote: Hello, We ran parfait on OpenSSL and found the following errors in openssl-1.0.1g: 1. Error: Uninitialised memory (CWE 456) Possible access to uninitialised me

Re: [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors

Thank you, Tim. >> 2. Error: Null pointer dereference (CWE 476) >> Read from null pointer rctx >> at line 114 of >> components/openssl/openssl-1.0.1/build/sparcv9-wanboot/crypto/ocsp/ocsp_ht.c >> in function 'OCSP_REQ_CTX_free'. >> Function OCSP_sendreq_new may return co

Re: [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors

Thank you, Tim. 2. Error: Null pointer dereference (CWE 476) Read from null pointer rctx at line 114 of components/openssl/openssl-1.0.1/build/sparcv9-wanboot/crypto/ocsp/ocsp_ht.c in function 'OCSP_REQ_CTX_free'. Function OCSP_sendreq_new may return constant 'NULL' at

Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)

On 9 June 2014 19:42, Kurt Roeckx via RT wrote: > On Sun, Jun 08, 2014 at 10:57:57PM +0200, Matt Caswell via RT wrote: >> Hi Quanah >> >> Thanks for the submission. The problem with correcting this is that >> technically >> it forms part of the public API (since the macro is defined in asn1.h). I

Re: [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors

Hi Tim, Thanks for your feedback! On 06/ 7/14 03:01 PM, Tim Hudson via RT wrote: > On 7/06/2014 7:10 PM, Jenny Yung via RT wrote: >> Hello, >> >> We ran parfait on OpenSSL and found the following errors in openssl-1.0.1g: >> >> 1. Error: Uninitialised memory (CWE 456) >> Possible access to u

Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)

On Mon, Jun 09, 2014 at 11:14:54AM -0700, Quanah Gibson-Mount wrote: > It could be fixed for 1.0.2 however, right? It's reasonable to expect the > API to change across major releases. The 1.0.2 release is NOT a major release. The ABI is supposed to be stable across both patch and micro releases

Re: Locking inefficiency

Geoffrey Thorpe : First, you're right, pthreads_locking_callback() is collapsing everything > to a mutex. > I was well aware of this and thought we did this for compatibility reasons (because I couldn't think of any other reasonable explanation, I guess). If actual read-write locks are just as p

Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)

On Sun, Jun 08, 2014 at 10:57:57PM +0200, Matt Caswell via RT wrote: > Hi Quanah > > Thanks for the submission. The problem with correcting this is that > technically > it forms part of the public API (since the macro is defined in asn1.h). I > guess > there's probably not a huge risk in changin

Re: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

Bump. On Fri, Jun 6, 2014 at 2:35 PM, Fedor Indutny wrote: > Hello everyone! > > Discovered this problem while trying to fix > https://github.com/joyent/node/issues/7704. > > Attached is a fix for it. > > Cheers, > Fedor. >

Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)

--On Sunday, June 08, 2014 11:57 PM +0200 Matt Caswell via RT wrote: > Hi Quanah > > Thanks for the submission. The problem with correcting this is that > technically it forms part of the public API (since the macro is defined > in asn1.h). I guess there's probably not a huge risk in changing it

Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)

--On Sunday, June 08, 2014 11:57 PM +0200 Matt Caswell via RT wrote: Hi Quanah Thanks for the submission. The problem with correcting this is that technically it forms part of the public API (since the macro is defined in asn1.h). I guess there's probably not a huge risk in changing it, as I

[openssl.org #3393] PATCH: EVP_SignInit.pod update

Its not clear that the signature's buffer size, `s`, is not used as an IN parameter. Under the current docs, the only thing stated is "at most EVP_PKEY_size(pkey) bytes will be written". Its kind of misleading since it appears EVP_PKEY_size(pkey) WILL be written regardless of the signature's buffe

[openssl.org #3392] EVP_SignFinal smashes the stack with RSA key. RSA key provides n,e,d,p,q.

EVP_SignFinal smashes the stack with RSA key. RSA key provides n,e,d,p,q. RSA_check_key OK. p and q were solved from n,e,d offline because the key check failed without it. * (gdb) r Starting program: /home/jwalton/openssl-test.exe Signature: 78f2c9af23b9a2a42e3b57dec454fa43ea6627992f48d40a33

Query reg multiple CA-Cert in list with same subject

Hi, I have a query for Ca-Cert list. If at gateway we have configured two CA-certs A1 and A2 both having same subject and content except time-stamp of generation. If peer sends Cert matching to A2, gateway tries to validate it with A1(subject being same and configured first in list) and validatio

Re: Locking inefficiency

It has been a while since I looked at this code, and I'd forgotten some of the convolution implicit in the "pluggability" of the ERR API. Something else for the TODO list I guess. I doubt that anyone is making use of that flexibility, and it would be massively simpler to carve it down to a single c

Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH

- Original Message - > From: "Matt Caswell via RT" > To: hka...@redhat.com > Cc: openssl-dev@openssl.org > Sent: Monday, June 9, 2014 1:01:05 AM > Subject: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out > difference between DH and ECDH > > * aNULL also includes some

Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH

- Original Message - > From: "Matt Caswell via RT" > To: hka...@redhat.com > Cc: openssl-dev@openssl.org > Sent: Monday, June 9, 2014 1:01:05 AM > Subject: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out > difference between DH and ECDH > > * aNULL also includes some

Re: [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors

On 8/06/2014 11:40 AM, Kurt Roeckx via RT wrote: > On Sun, Jun 08, 2014 at 12:01:28AM +0200, Tim Hudson via RT wrote: >> Already fixed in the 1.0.1 stable branch so it is already included in >> 1.0.1h onwards and 1.0.1m is the current recommended version. > [...] >> Can you re-run parfait against t