Hi,

>> Tracking the bug I think it is in the seeding process, when
>> 'RAND_file_name' is invoked it returns a file called 'c:\/.rnd', since that
>> looked weird for a file name I hardcoded it to be 'c:/.rnd', which seems to
>> have taken care of the error.
 
>So do you actually have such a file, or why was this a problem?

No, the file doesn't exist and in other cases where the file is
c:\msys\home\andres/.rnd it doesn't exist either, but that doesn't seem
to bother openssl.

As for why, I don't know, I have been trying to see how that can affect
SSL_connect to make it return a 'not successul but was shut down controlled',
but haven't found it yet.

>Anyhow, I
>don't understand how this can make you succeed the second time you run it...
 
No, the fail first and succeed later happens with the unmodified code, because
of this:

  if(!ssl_seeded || data->set.ssl.random_file || data->set.ssl.egdsocket) {
    /* Make funny stuff to get random input */
    random_the_seed(data);
    ssl_seeded = TRUE;
  }

random_the_seed is only invoked the first time, so it works in the following
performs.

With the hardcoded path it always works, not that is a real solution.

> libcurl doesn't set any file names like that. RAND_file_name() is documented
> to generate "a default path for the random seed file". So if that name is
> bad, then I guess OpenSSL is to blame.
 
Well, I will try to contact the openssl guys and see if they understand what
is going on.

Andres

-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
Received on 2003-05-23