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.html
