On Wed, 30 Aug 2017, Kamil Dudka wrote:

> Should the curl_global_sslset() function really be declared in
> <curl/multi.h>? I though that the include file was used solely for the
> libcurl multi API...

Yes you're of course right, but..

Some platforms build the list of public API calls from our public header
files when they build libcurl. And in order to not break ABI compliance with
older builds, we can only add functions last in those lists. So, we can
actually only add functions at the end of multi.h or require an ABI
bump for those.

I'm not really suggesting that this is a long-term solution or even very nice,
but it was a way to drive this forward right now anyway. I'm sure we'll have
(more) reasons to clean this up in the future. Especially when the next added
function call is considered...

> This is caused by using NSS for the crypto operations despite only OpenSSL
> was initialized. Should the switch work for SSL only or should it work for
> the low-level crypto operations, too?

I don't think it matters, does it? The low level crypto functions should just
work no matter which backend that provides them. Swichting or not, I mean.

> A lightweight solution would be to fix curl_ntlm_core.c such that it uses
> crypto operations from the default SSL/crypto backend. This would fix the
> breakage in the most common case. However, NTLM would still break if the
> SSL backend was switched at run-time.

We're selecting which SSL backend to use before anything used curl for the
first time and then never again for the process life time - at least for the
time being.

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