Bugs item #1960645, was opened at 2008-05-08 17:01
Message generated for change (Comment added) made by brianwski
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1960645&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: https
Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Wilson (brianwski)
Assigned to: Daniel Stenberg (bagder)
Summary: OpenSSL RAND_file_name() on Windows when no "C" drive

Initial Comment:
Using: libCURL 7.17.0

A customer of ours (we link with libCURL) had a Windows XP Professional machine with the situation of not having a "C" boot drive, the machine was configured with "F" as it's boot drive, and "C" is configured as the built-in flash card reader. Blech!

In this case, using libCURL to fetch an HTTPS URL caused an error dialog to appear on the customer's
Windows desktop saying "Windows No Disk".

I chased it down to the call in ssluse.c (line 252):
   RAND_file_name(buf, BUFSIZE);
which is an OpenSSL call. If you make that call on Windows and do not have a "C:" drive, then Windows pops up the dialog saying "Windows No Disk". Every time. 100 percent reproducible.

The work-around I put into our source tree VERY QUICKLY (and probably is not correct) is to replace that single line of "RAND_file_name(buf, BUFSIZE);" with the source code below (this fix lowers the randomness slightly for the case where customers do not have a "C" drive):

#ifdef _WIN32
  // The OpenSSL call to "RAND_file_name()" causes
  // problems if you do not have a "C:\" drive
  //
  {
      char pathToSystemDir[200];
      HRESULT res = SHGetFolderPath(NULL,
          CSIDL_SYSTEM, NULL,
          SHGFP_TYPE_CURRENT, pathToSystemDir);

      if (tolower(pathToSystemDir[0]) == 'c')
      {
          RAND_file_name(buf, BUFSIZE); // OK!
      }
  }
#else
  RAND_file_name(buf, BUFSIZE);
#endif

BTW, libcurl is awesome, thanks for all the great code.

-- Brian Wilson
   brianwonline453_at_codeblaze.com

----------------------------------------------------------------------

>Comment By: Brian Wilson (brianwski)
Date: 2008-05-08 18:02

Message:
Logged In: YES
user_id=2082650
Originator: YES

I would definitely call this an OpenSSL bug (more on that below). But I
would assume libCURL doesn't want to have bad behavior while waiting for
the OpenSSL fix.

The OpenSSL file "crypto/rand/randfile.c" implements "RAND_file_name()"
and if you do not have a HOME environment variable set it looks to me like
it hard codes it to "C:\" on Windows, which is SOOOOOO not correct in a
Windows world. :-) A HOME environment variable is not a necessary part of
running a Windows desktop (in fact it's quite unusual).

Of course, maybe the OpenSSL guys would claim libCURL should set a HOME
environment variable, but I think that's hacky, there are perfectly
acceptable calls on Windows to return the correct drive letter, and OpenSSL
should call them.

> Any references to C: drive....

Not that I can find. This user has trouble with his "non-standard" config
all the time. A decent amount of software (like OpenSSL) hard codes "C:"
and this user has run this machine like this for 3 years and has issues
here and there that have to be dealt with. I don't think this is a very
common config. Personally I *ALWAYS* configure my Windows system to boot
from C. It's too much hassle to buck the trend.

-- BrianW

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2008-05-08 17:45

Message:
Logged In: YES
user_id=236775
Originator: NO

This sounds like a configuration problem or OpenSSL bug, not a libcurl
bug. Were there any references to C: drive in the environment at the time,
especially TEMP, TMP, and USERPROFILE?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1960645&group_id=976
Received on 2008-05-09