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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
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.
[1]: https://github.com/curl/curl/pull/9589
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.
[1]: https://github.com/curl/curl/pull/9589
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-25