Re: Enabled multiple SSL backends
Date: Wed, 30 Aug 2017 10:21:58 +0200
On Wednesday, August 30, 2017 10:14:06 AM CEST Daniel Stenberg wrote:
> 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...
OK. I should have read the commit message first :-)
> > 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
> > 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.
The point is that it does not work well if you initialize only OpenSSL (either
be it compile-time default, or run-time selected backend) and then you try to
use low-level crypto from NSS.
Received on 2017-08-30