On 03/12/14 05:01, Dominyk Tiller wrote:
Hey guys,
I wanted to query something I saw pop up on the Git earlier:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=961d2ddb4b48e0e857a704b0cc6b475d63372419
Does that change imply that right now, without that commit, building
without
Hai All,
We are using Openssl for DTLS Negotiations. When we run the Valgrind
with this setup. We are finding some major loss of memory at one place.
==23871== 4,224 (1,056 direct, 3,168 indirect) bytes in 3 blocks are
definitely lost in loss record 1,332 of 1,482
==23871==at 0x4C26BED:
On Wed, Dec 03, 2014 at 04:04:16PM +0530, T@Run..! Polisetty wrote:
Hai All,
We are using Openssl for DTLS Negotiations. When we run the Valgrind
with this setup. We are finding some major loss of memory at one place.
Can you check with a current git version? There have been
Actually it does not introduce it as OpenSSL does send the notification as
TLS_EMPTY_RENEGOTIATION_INFO_SCSV, not the extension.
The skip is also placed in t1_lib.c after the handle for RI (Renegotiation
Info), so renegotiation is performed using the secure protocol.
And while it would be nice
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
thanks! Was away last week and so didn't have a chance to try fixing this.
I'll patch that it and run the tests against it.
I've run out of time tracking this down for today, but I got to the
point where setting the Jacobian coordinates:
X:
... and same in cherry-picked variants in other branches:
05e769f269f28b649d8300a1fc3aaef19901a173 (OpenSSL_1_0_2-stable)
4c21e004a3738b70c7d21d6e86ca68b21577d4d0 (OpenSSL_1_0_1-stable)
Appears harmless, though.
Look for Just one protocol version:
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index
2. When will RT2574 be integrated to protect our ECC keys in the
inevitable presence of software defects like this?
http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest
Reportedly, Cryptography Research (i.e., Rambus) alleges to have broad
patents on techniques like this
This is an initial patch to support being able to set the minimum
and maximum protocol version. The patch is currently untested,
that will happen as I rewrite other things. But I'm looking for
feedback.
Kurt
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index ab8730c..6a016f0 100644
---
On 03/12/14 20:36, Yuriy Kaminskiy wrote:
... and same in cherry-picked variants in other branches:
05e769f269f28b649d8300a1fc3aaef19901a173 (OpenSSL_1_0_2-stable)
4c21e004a3738b70c7d21d6e86ca68b21577d4d0 (OpenSSL_1_0_1-stable)
Appears harmless, though.
Thanks. I'll get this fixed.
Matt
On Wed, Dec 3, 2014 at 10:12 AM, Andy Polyakov via RT r...@openssl.org wrote:
Oops! Wrong patch! Correct one attached. If you feel like testing the
wrong one, go ahead, but there are some later non-essential adjustments.
diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c
index
13 matches
Mail list logo
