cURL / Mailing Lists / curl-users / Single Mail

curl-users

RE: https problems

From: David Byron <DByron_at_everdreamcorp.com>
Date: Fri, 11 Feb 2005 14:15:51 -0800

On Fri, 11 Feb 2005, Bill Mercer wrote:

> I just downloaded the Windows Generic version 7.13 from the
> link on the site, and I can confirm it still does this to me.
>
> Using version 7.11, this works:
> curl -k http://www.netscape.com
>
> With version 7.13, the same command gives the error I
> described earlier.
> I also get the same error when I type this...
>
> curl -k http://no.such.address
>
> or even this...
>
> curl -k blahblahblah

The same thing happens to me that happens to Bill. I downloaded a few
more versions of curl-<version>-win32-ssl.zip from
http://curl.haxx.se/download and may have narrowed the problem a bit
further. Here's what I found:

7.11.0 -- works
7.12.0 -- works
7.12.2 -- works
7.12.3 -- broken
7.13.0 -- broken

I started looking through the code at what it could be. I didn't find
anything super obvious, but:

in lib/getenv.c -- the GetEnv() function
----------------------------------------
- I'm not sure how you decide that MAX_PATH is long enough to hold the
CURL_CA_BUNDLE environment variable. I think that's probably OK though.
But, I think env should have MAX_PATH + 1 bytes allocated to it, and
then ExpandEnvironmentVariables should only get sizeof() - 1 passed to
it. That way you're guaranteed a NULL terminator at the end.

- We really should check the return value of ExpandEnvironmentStrings,
if nothing else but to log something. If it returns 0, GetLastError is
supposed to say why. The docs I read
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinf
o/base/expandenvironmentstrings.asp) don't say what happens to the lpDst
variable on failure, but I wouldn't depend on it being anything in
particular.

in src/main.c -- operate()
--------------------------
- The memory returned by GetEnv is allocated by strdup. Then in
operate(), we copy it again in GetStr() with strdup. Maybe we could
remove one of these?

Nothing above should be the problem at least on my machine, since the
CURL_CA_BUNDLE environment variable isn't defined.

- line 2870 of main.c(1.310) passes MAX_PATH+2 to SearchPathA in a place
where I think it should either pass MAX_PATH or MAX_PATH+1 depending on
who accounts for the NULL termination. To be safe, I'd pass MAX_PATH.

- on line 2872 we make a copy of the return value that I don't think we
need.

I see that the zip files all put curl-ca-bundle.crt in the same
directory as curl.exe. My results are the same whether the file is
there or not. It's not there in the src directory in CVS.

Without diffing source files to find out what changed in 7.12.3, there's
a comment about the IOCTLFUNCTION stuff being for 7.12.3. This is a
stretch, but my_ioctl (in src/main.c) should probably be checking userp
for NULL before derefencing it. From what I can tell, in->stream is
equal to stdin so even if it's not OK to fseek on stdin, it shouldn't
crash.

Maybe this is enough for someone else to see what the real problem is?

-DB
Received on 2005-02-11