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 the
- Original Message -
From: Matt Caswell via RT r...@openssl.org
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
- Original Message -
From: Matt Caswell via RT r...@openssl.org
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
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
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
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:
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 buffer
--On Sunday, June 08, 2014 11:57 PM +0200 Matt Caswell via RT
r...@openssl.org 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
--On Sunday, June 08, 2014 11:57 PM +0200 Matt Caswell via RT
r...@openssl.org 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
Bump.
On Fri, Jun 6, 2014 at 2:35 PM, Fedor Indutny fe...@indutny.com 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.
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 changing it,
Geoffrey Thorpe ge...@geoffthorpe.com:
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
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.
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
On 9 June 2014 19:42, Kurt Roeckx via RT r...@openssl.org 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
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'
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
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
Hey Bodo,
On Mon, Jun 9, 2014 at 3:15 PM, Bodo Moeller bmoel...@acm.org wrote:
Geoffrey Thorpe ge...@geoffthorpe.com:
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
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
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 =
21 matches
Mail list logo
