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: curl_version_info() thread-safety

From: Ray Satiro via curl-library <>
Date: Sun, 25 Sep 2022 03:00:18 -0400

On 9/24/2022 12:22 PM, Patrick Monnerat via curl-library wrote:
> I just noticed curl_version_info() is not thread-safe when compiled
> with multi-ssl backends because the HTTPS-proxy feature bit is
> computed at run-time and may change between calls.
> This is the case until the effective SSL backend is selected
> (curl_global_sslset() or curl_global_init()).
> I have been wondering quite a long time about what to do against that
> and the "least bad" solution I can imagine is to always consider the
> HTTPS-proxy feature as absent when MultiSSL is enabled, even after the
> effective SSL backend has been selected.
> The cost is an application would not be able anymore to select a
> backend then use version info to see if it support HTTPS-proxy. That
> said, features never were intended to be dynamic.

Shouldn't the backend have been selected via ssl initialization by the
time multissl_version is called? There is also multissl_setup which is
called by a bunch of multissl_ functions and not protected by a lock,
for example multissl_getsock, multissl_close call it. That doesn't make
a lot of sense to me. I've submitted a PR [1] that would protect the
functions with a lock but I don't understand exactly why we need it if
the user is using libcurl as intended. There are a bunch of functions
that call multissl_setup after initialization, I don't know why though.


Received on 2022-09-25