> The whole point is to allow the user to decide which CA to trust and
> which to not trust. Trust is a funny thing but you can't shove trust
> onto somebody and force them to trust someone. That's not trust,
> that's something else.

This is ok when the user is just a single person, we should of course
trust him to do the right thing. But when the user is a large organization
it is the authorities in that organization who determines who everyone
in the organization should trust. Under that scenario, the individual
user should not be allowed to tamper with the list of root CAs. This
is the situation we are facing.

>>> 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.
>
> Ok, that's your choice. If you can't stand up and argue for your
> feature then I think even more that is for the best.
>

Its not my choice, but I can live with that. We incorporate a new libcurl
say once a year and it takes just an hour to apply the changes so it is not
a big deal. I can of course stand up and argue for my feature, but if no
one else is going to need it, its best that the changes are kept private.
That CURLOPT_SSL_CTX_FUNCTION looks interesting in that it allows us to
plug in to libcurl and do our stuff. I am thinking of enhancing that option
to do our stuff if you think the CURLOPT_CACERTSTORE is not for everyone, but
that will change the prototype of the callback function, is that ok? will it
break backwards compatibility? The callback function will have to be changed
as it needs another parameter to say when it is being called as
it needs to be called twice, once on creation and once before exit.

>> I can't make this feature for non-openssl, as I don't know much about them.
>
> Of course you *can*. The fact that you didn't and didn't bother to
> even consider it is another matter. Heck, I'm personally guilty of
> adding features that are OpenSSL specific so I'm perfectly aware of
> what it means and takes.
>

I don't understand this part. I know only about OpenSSL. I don't know
*even the names* of the others so how can I program for them? Mastering
OpenSSL was itself a large task and I am not sure I have the time or desire
to get to know other SSL packages.

> In this specific case you basically didn't even make the libcurl
> code very OpenSSL specific but left all of that for the application
> code so I believe it would be a relatively small effort.

No I didn't. It is OpenSSL that still does the bulk of the work. I am merely
tweaking OpenSSL to use my cert store instead of what it usually loads.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-05-14