Hello Larry,
OpenSSL message digest implementations trigger
bug[s] in code optimizer in gcc 3.3 for sparc64. So this fails to complete
RIPEMD160 test. It is already addressed as Bugs in gcc triggered Section
in./PROBLEMS file of openssl Souce release.
The recommendation is to upgrade your
Hi all,
I have written a program which does RSA_private_decrypt() repeatedly with
a private key given with PEM format.
I also derive private key with BIO_new_mem_buf() and
PEM_read_bio_RSAPrivateKey()
functions, so the brief code is as follows.
bioPtr = BIO_new_mem_buf( InputPEMstring, -1 );
In message [EMAIL PROTECTED] on Tue, 20 Jun 2006 21:16:49 +0900, Tatsuya
Tsurukawa [EMAIL PROTECTED] said:
Tsurukawa.Tatsuya bioPtr = BIO_new_mem_buf( InputPEMstring, -1 );
Tsurukawa.Tatsuya :
Tsurukawa.Tatsuya prvkey = PEM_read_bio_RSAPrivateKey( bioPtr, NULL, NULL,
NULL );
Tsurukawa.Tatsuya
I have some code what was originally doing:
HMAC_CTX ctx;
HMAC_Init(ctx, key, keylen, EVP_md5());
HHAC_Update(ctx, data, datalen);
HHAC_Update(ctx, moredata, moredatalen);
HMAC_Final(ctx, digest, digestlen);
This seems to work fine and valgrind indicates there are no memory
leaks, i.e.
Sorry to come at this thread a week later.
I can see both sides of the problem here, there are infact three
distinct modes of operation:
Non-Blocking: There is where the underlying socket descriptor is in
non-blocking mode. SSL API calls return -1 and set SSL_get_errno() to
allow for
Dow! Ignore my post.
My system openssl/hmac.h and the one of openssl-0.9.8b I am using have
different sized structures and part of my code (a sub-library) wasn't
building against it. Probably Fedora removing legally problematic code.
Darryl
If I understand correctly the original thread poster was explaining a
bug in using OpenSSL s_client triggered during a renegotiation (was this
client or server initiated? SGC related?).
- client sends some data
- server initiates renegotiation and immediately after that sends some
data
Mikhail Kruk wrote:
It is unclear to me if Marek
thinks this problem is due to a library bug or simply that s_client
should be clearing SSL_MODE_AUTO_RETRY in its block socket use case for
that program. We all know that OpenSSL s_client has a command line
option to enable nonblocking mode so
Well, if s_client is broken in the blocking mode maybe it should be
removed completely. I did test it in the non-blocking mode and, of
course, it does not have the described error.
So are you saying the bug is:
* in s_client (for not correctly handling the SSL layer APIs) or
Mikhail Kruk wrote:
I'm pretty confident that the fix (if it is feasible) is not going to
break any correct application code.
And I'm pretty confident that it is going to make app. engineer's life
easier.
My view comes from what is architecturally scalable by design which
makes it recursive
My first reaction was that this is a bug in the library, but I
didn't feel
very strong about it and would have accepted that this is just a bug in
s_client. I like your argument about the library not having the right to
make 2 blocking calls unless retry is set and now I'm back to thinking
David Schwartz wrote:
My first reaction was that this is a bug in the library, but I
didn't feel
very strong about it and would have accepted that this is just a bug in
s_client. I like your argument about the library not having the right to
make 2 blocking calls unless retry is set and now I'm
If anyone thinks that 'select' or 'poll' guarantees that a future
operation
will not block, even if it's a single operation, that's just plain not true.
The only way you can guarantee that even one operation will not block is if
you set the socket non-blocking.
Really.
I dont
If anyone thinks that 'select' or 'poll' guarantees that a
future operation
will not block, even if it's a single operation, that's just
plain not true.
The only way you can guarantee that even one operation will not
block is if
you set the socket non-blocking.
Really.
I
Linux:
Three independent sets of descriptors are watched. Those listed in
readfds will be watched to see if characters become available for read-
ing (more precisely, to see if a read will not block - in particular, a
file descriptor is also ready on end-of-file)
You'll
Hello,
If anyone thinks that 'select' or 'poll' guarantees that a future
operation
will not block, even if it's a single operation, that's just plain not
true.
The only way you can guarantee that even one operation will not block is
if
you set the socket non-blocking.
Dear Richard,
Thank you for your quick answer.
I did nothing after RSA_private_decrypt() error(-1) with a wrong private
key and called ERR_get_error() right after BIO_new_mem_buf() returned NULL
as follows.
iRet = RSA_private_decrypt(); // provide wrong private key
if( iRet == -1 ){
//
You are now introducing some weirdness into our little blocking world.
Threads and other scary stuff. Yes, if a gremlin reads the data from the
buffer between calls to select() and read(), the read() call
might block.
But if we assume that there is only one process with single thread using
One more point, and then I'll try to shut up. ;)
You could argue that we could just fix this and deprecate fake
non-blocking I/O for future major versions. The argument would be that this
won't break any application that's not broken already and might fix existing
applications.
On Tue, Jun 20, 2006 at 07:50:24PM -0700, David Schwartz wrote:
You could argue that we could just fix this and deprecate fake
non-blocking I/O for future major versions. The argument would be that this
won't break any application that's not broken already and might fix existing
applications.
Perhaps the backtracking to reprocess the event as data involves a
second blocking socket read() in ssl3_read_bytes(). I am not familiar
with the details of this code. What I am curious about is when does
this happen. What is it exactly that the server is doing here, why,
and is it legal?
In message [EMAIL PROTECTED] on Wed, 21 Jun 2006 10:44:33 +0900, Tatsuya
Tsurukawa [EMAIL PROTECTED] said:
Tsurukawa.Tatsuya It seems I need to clear error queue after private
Tsurukawa.Tatsuya decryption error, but does the status of error
Tsurukawa.Tatsuya queue actually affect to the
So the question is whether it is legal for the server to send data while
renegotiation is in progress?
The server is not supposed to be required to track whether
renegotiation is
in progress or not. If you try to send data while a renegotiation is in
progress, the OpenSSL library is
23 matches
Mail list logo
