p versions
(1.0.2a/b)? I would prefer not having to wait with that till 1.1.0.
cu,
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
--- openssl-1.0.2-stable-SNAP-20150115/ssl/ssl_ciph.c 2014-12-17 15:01:30.0 +0100
+++ openssl-1.0.2-stable-SNAP-20150115-hash/ssl/
Matt,
Thank you for the support. This was lucrative and good response time!
Best regards,
Andrei
> On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT
> wrote:
>
> Hi all,
>
> I believe I have found a bug which is only present in the latest versions
> (1.0.1k)
>
> I have created a si
Matt,
Thank you for the support. This was lucrative and good response time!
Best regards,
Andrei
> On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT
> wrote:
>
> Hi all,
>
> I believe I have found a bug which is only present in the latest versions
> (1.0.1k)
>
> I have created a si
When using EVP_DigestSign and EVP_DigestVerify functions, errstr
cannot decode a failed verification error under RSA.
To duplicate, create a signature with EVP_DigestSign. Tamper with the
signature: sig[0] ^= 0x1. Then run it through EVP_DigestVerify.
In the case of OpenSSL 1.0.1:
$ ./t-rsa.exe
Matt,
Thank you for reply.
May I ask you when do you think your patch may land in 1.0.2 or whatever?
If this is something of your long term goals and not going to land anywhere
soon. Could you please tell me about issues in my patch (either privately
or in publiс)?
Thank you again,
Fedor.
On T
On Thu Jan 15 17:01:51 2015, shir...@gmail.com wrote:
> Hi all,
>
> Also, just for completeness, I want to point out I'm a fortunate case
> where I can actually touch the code and recompile it to fix the
> issue. I'm sure that other cases are not so fortunate. IMHO, when
> DTLS method is used, that
Hi all,
Also, just for completeness, I want to point out I'm a fortunate case where I
can actually touch the code and recompile it to fix the issue. I'm sure that
other cases are not so fortunate. IMHO, when DTLS method is used, that call
should be made by default in the internals of OpenSSL
B
Hi all,
Also, just for completeness, I want to point out I'm a fortunate case where I
can actually touch the code and recompile it to fix the issue. I'm sure that
other cases are not so fortunate. IMHO, when DTLS method is used, that call
should be made by default in the internals of OpenSSL
B
Hi,
Adding "SSL_CTX_set_read_ahead(pSslContext, 1);" fixed both the test app and
the real app I'm working on.
May I ask where should I read more about this function? I'm grateful that it
now works, but is kind of a tough thing to just swallow this info without
chewing on it a bit :)
Best rega
Hi,
Adding "SSL_CTX_set_read_ahead(pSslContext, 1);" fixed both the test app and
the real app I'm working on.
May I ask where should I read more about this function? I'm grateful that it
now works, but is kind of a tough thing to just swallow this info without
chewing on it a bit :)
Best rega
This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here
is a brief analysis:
Consider sv_body() in server.c
2237 con=SSL_new(ctx);
Here a new context is initialized. From ssl_lib.c:295, this also causes the
krb context to be initialized via
295 s->kss
This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here
is a brief analysis:
Consider sv_body() in server.c
2237 con=SSL_new(ctx);
Here a new context is initialized. From ssl_lib.c:295, this also causes the
krb context to be initialized via
295 s->kss
On 15/01/15 14:21, Matt Caswell wrote:
>
>
> On 15/01/15 14:13, Fedor Indutny wrote:
>> Hello!
>>
>> During the course of deprecation of stale 1024bit CA certs,
>> node.js and io.js project teams have identified the problem with
>> how OpenSSL client handles the server's certificate chain. It i
On 15/01/15 14:13, Fedor Indutny wrote:
> Hello!
>
> During the course of deprecation of stale 1024bit CA certs,
> node.js and io.js project teams have identified the problem with
> how OpenSSL client handles the server's certificate chain. It is
> quite evident that it ignores certificate store
Hello!
During the course of deprecation of stale 1024bit CA certs,
node.js and io.js project teams have identified the problem with
how OpenSSL client handles the server's certificate chain. It is
quite evident that it ignores certificate store and loads issuer
from the chain that was received. Th
On Thu Jan 15 14:25:54 2015, sidhpurwala.huza...@gmail.com wrote:
> Here is how to test it:
>
> openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt
> -subj \
> /CN=localhost -nodes -batch -sha256
>
> valgrind --leak-check=full openssl s_server -key localhost.key -cert \
> localho
Here is how to test it:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \
/CN=localhost -nodes -batch -sha256
valgrind --leak-check=full openssl s_server -key localhost.key -cert \
localhost.crt -accept 4433
./poc.py
Every run of poc.py causes 56 byte memory leak:
Here is how to test it:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \
/CN=localhost -nodes -batch -sha256
valgrind --leak-check=full openssl s_server -key localhost.key -cert \
localhost.crt -accept 4433
./poc.py
Every run of poc.py causes 56 byte memory leak:
On Wednesday 14 January 2015 18:01:05 Prabhat Chauhan via RT wrote:
> Dear Sir,
>
> When i try to compile and run my Bitcoin code in fedora 18. It give me error
>
> root@localhost bitcoin-0.10.0rc1]# bitcoind
>
> *Error: OpenSSL appears to lack support for elliptic curve cryptography.
> For more
On Thu Jan 15 10:38:58 2015, sidhpurwala.huza...@gmail.com wrote:
> Hi,
>
> I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
> bytes for each connection request.
>
> Patch is attached.
I'm not seeing this memory leak. The kctx object should be being freed in the
call to SSL
Hi,
I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
bytes for each connection request.
Patch is attached.
patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/op
Please could you try making the following call:
SSL_CTX_set_read_ahead(ctx, 1);
Insert it immediately after these lines in your test code:
pSslContext = SSL_CTX_new(DTLSv1_server_method()); assert(pSslContext != NULL);
assert(SSL_CTX_use_certificate(pSslContext, pX509) == 1);
assert(SSL_CTX_use_P
According to https://www.openssl.org/docs/crypto/EVP_DigestVerifyInit.html,
EVP_DigestVerifyFinal does not take a const pointer.
The signature already exists, and it was passed into the function as a
'const unsigned char*'.
This creates a compile problem in practice:
t-hmac.c:212:41: warning: pa
Seeing the memory leak (process DTLS server) in the latest released 1.01k
version on the server side. Any clue as to how to get this fixed?
Regards
-Praveen Kariyanahalli
==1162== 36,480 (1,920 direct, 34,560 indirect) bytes in 30 blocks are
definitely lost in loss record 119 of 130
==1162==a
24 matches
Mail list logo
