curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?

From: Timothe Litt <litt_at_acm.org>
Date: Thu, 26 May 2022 15:44:17 -0400


On 20-May-22 02:59, Daniel Stenberg wrote:
> On Thu, 19 May 2022, Timothe Litt via curl-library wrote:
>
>> It would be nice to have a curl_easy_getinfo() along the lines of:
>>
>> |curl_easy_getinfo(CURL *curl, CURLINFO CURLINFO_CAINFO, char
>> **path)| to get a string with the current bundle path for a handle
>
> Maybe this?
>
> https://github.com/curl/curl/pull/8888
>
Sorry to be slow responding; busy time here.  Thanks for picking up on this.

That's close to my idea, but:

Not clear why we need the CURL *handle to get just the (built-in)
default strings.  The handle is ignored for these INFO codes, right?

OTOH, if something was set for a handle by the user, it would be nice to
get that - e.g. for the "generate C code" or "generate curl command"
APIs.  That's what I meant by "current bundle path for a handle".  You
could do both with one INFO code per string.

So I thought the INFO calls might use a NULL handle to get the default
string, and a valid handle to get whatever the string has been set to
for that handle.  If the handle-specific string is unset, the latter
case could either return NULL or a pointer to the default.

Sorry if that wasn't clear earlier.

In any case, your PR does meet the minimum requirement of exposing the
default string computed by the build (configure, cmake, etc.)  Thanks
for that.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.


-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2022-05-26