On Sat, 15 Jan 2005, Jochen Roderburg wrote:

> it is initialised there like
>
> 354:#ifdef CURL_CA_BUNDLE
> 355- /* This is our prefered CA cert bundle since install time */
> 356: data->set.ssl.CAfile = (char *)CURL_CA_BUNDLE;
> 357-#endif
>
> and I assume this is not done in the Windows version.

Right, it remains NULL then until set with the library option CURLOPT_CAINFO.

> With this theory I was also now able to simulate the error under Linux. I
> replaced the above line with data->set.ssl.CAfile = -1 and now I get also a
> chrash under Linux with -k.

But -1 is an invalid value for that pointer. It should be NULL or point to a
zero terminated file path.

> And indeed, in the function Curl_clone_ssl_config the variable CAfile is
> used in a strdup call:
>
> 3687: if(source->CAfile) {
> 3688: dest->CAfile = strdup(source->CAfile);
> 3689: if(!dest->CAfile)
> 3690- return FALSE;
> 3691- }

... and the check on line 3687 prevents the strdup() to attempt to clone a
NULL pointer.

> Of course there are some unproven parts in this theory, because I cannot see
> what the CAFile really contains in the Windows case. That would now need
> some real debugging there.

It is initiated to NULL in the library. If the app doesn't find the cert using
the env variable and search logic, then it won't set the CURLOPT_CAINFO option
and it should thus remain NULL...

And, in the code in lib/ssluse.c where the cacert path would be used, it too
checks if the value is non-NULL before it uses it.

To sum it up: I don't see where this is a problem. But maybe I'm blind!

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html