Re: Get for CURLOPT_CAINFO, CURLOPT_CAPTH?

On 26-Mar-20 12:35, Daniel Stenberg wrote:
> On Thu, 26 Mar 2020, Timothe Litt wrote:
>
>> The man page for the curl command says that the command line version
>> of curl pays attention to environment variables CURL_CA_BUNDLE
>> (oddly, there's no mention of a CURL_CA_PATH variable...)
>
> Why is that odd? It's decision to support the bundle with an
> environment variable. The directory approach is a mostly legacy and
> OpenSSL-centric thing that has less use in a world with a wide variety
> of TLS backends.
>
I'm not complaining, just observing.

It seems odd because there are two closely related mechanisms for
specifying trusted certificates.  Everywhere else, they are paired.  But
here, one has an environment variable, and the other does not.  So it
seems odd.  Not necessarily wrong.  But odd.

Note that OpenSSL has SSL_CERT_DIR and SSL_CERT_FILE.  And it evaluates
them in the library - see
https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_default_verify_paths.html

Is that unique to the command line, or does libcurl do all or some of
the work?
>
> That's command line tool logic. It explictly says "If you're using the
> curl command line tool" ...
>
Yes, but since I know that some libraries look at envvars, it wasn't
clear whether the statement was about
the effect or the implementation.  If the library did the work, the
statement as written would still be true...

>> https://curl.haxx.se/docs/sslcerts.html isn't quite clear on what the
>> library alone does.  I read it as the library does not look at
>> anything except what is set explicitly by curl_easy_setopt(),  the
>> built in default, or the library's default - in that order of
>> preference.  But the description intermixes the library and command
>> tool so it's difficult to follow.
>
> If you can think ways to improve that document/language, please suggest!
>
There's a lot of useful information on the page, but the audience level
and organization are inconsistent.

I suggested a table, but that doesn't work for you.  I'm a newcomer to
this page and as someone who (at the moment) is only interested in
understanding the library's behavior, my biggest issue is that the text
bounces between the command tool and the library.  And in the middle,
throws in configure, browsers, and s_client.

It also starts with the basics of certificate trust - which is fine -
but talks about NSS as though everyone would know what NSS is.  If you
don't, the NSS discussion is very opaque.

I'm deep in the middle of several projects at the moment, but I'm
willing to take a stab at improving it when I get free.  Can you point
me to the page source?
>> Also, Item 2 on that page is somewhat confusing - for the command
>> line, it suggests --cacert (which is a bundle - maybe just the one
>> cert).  But for the library, it suggests setting CURLOPT_CAPATH
>> (which is a directory - in which, modulo hashing, you could ADD the
>> one cert). 
>
> That appears like an oversight. I think it should rather mention
> CURLOPT_CAINFO.
Agreed - that's what I thought most likely.
>
>> I'm going to send the version_info values back into curl as well as the
>> other library (with my own override mechanism), so it doesn't make a
>> difference for me.  But you might consider something like a table for
>> the page - one for the command tool's behavior/options, and one for the
>> libraries...
>
> There are also many more combinations than just tool vs library, like
> Windows vs non-Windows and OpenSSL vs non-OpenSSL vs NSS etc. Also,
> tables are tricky in text/markdown.
>
I understand.  The challenge is figuring out how to organize that for an
end user of the library and/or command line tool. 

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html