cURL / Mailing Lists / curl-library / Single Mail



From: <>
Date: Thu, 12 May 2011 05:25:33 -0700

> I wouldn't call that a "major weakness". I think you're bending the
> existing feature to better suit your slightly unusual corner case.

How then is the list of root certificates protected against tampering? Or
is that precaution unnecessary for anything except my unusual corner case?
What is the point of trusting root certificates that can be tampered easily?
We might as well turn off https and communicate in the clear.

> I'm not convinced this is a feature we need in libcurl - and if we
> do, your implementation of it is far too OpenSSL-specific.

OK. We will apply the changes only to our software, as and when we incorporate
the latest curl into our software. I can't make this feature for non-openssl,
as I don't know much about them.

> Also note that your patch has several irrelevant changes that have
> nothing to do with the specific feature you're working on. It is
> important that we keep changes separate and that each patch fixes
> only the intended issue.

I forgot about those changes. I needed to make those changes to make libcurl
work for me. LoadLibrary resolves to LoadLibraryW in my system whereas it
should resolve to LoadLibraryA always. So these changes make the code more
robust. If you insist I will submit a separate patch for that.

> Can't you accomplish the same thing by using an existing callback
> already? For example the CURLOPT_SSL_CTX_FUNCTION one ?

I checked out this option, suppose that when my function is called I replace
the cert store with my certstore. Will my function get called again when the
SSL_CTX is about to be destroyed, so that I can restore the previous store
so my store is not destroyed?

Please don't hesitate to contact me for further assistance or information.
Thanks and best wishes.
Shankar Software.
New 14, Old 8 Shankarapuram First Street,
Tamil Nadu.
India - 600094.
Cell - +91-9841111718.
List admin:
Received on 2011-05-12