Hi Kamil,

On Sat, 9 Sep 2017, Johannes Schindelin wrote:

> Actually, there is a remaining problem with that PR (which was sadly
> closed, but I think we need to get this problem fixed ASAP): when
> compiling cURL with NSS and, say, Secure Channel support, and Secure
> Channel is selected at runtime, then Curl_nss_init() will not have been
> called, ergo nss_initlink won't be initialized, and hence
> Curl_nss_force_init() will complain thusly:
>
> unable to initialize NSS, curl_global_init() should have
> been called with CURL_GLOBAL_SSL or CURL_GLOBAL_ALL
>
> I see that you added this test yourself, in f3b77e561 (http_ntlm: add
> support for NSS, 2010-06-27).
>
> So I see two options to move forward, building on PR 1848:
>
> 1) move NSS *waaaay* down in the #if..#elif chain in curl_ntlm_core.c
>
> 2) change Curl_nss_force_init() so that it can be called *without*
> Curl_nss_init() having been called before that.
>
> The easier method would be 1), I guess.
>
> For 2), we could introduce yet another lock (or a super-ugly workaround by
> calling Curl_nss_init() directly from Curl_ssl_init() if NSS is not the
> current backend and neither OpenSSL nor GNU TLS support was compiled in).
>
> What do you think?

Update: PR 1848 was reopened (I am really happy about that), and 1) was
chosen as the best way forward.

Ciao,
Johannes
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-09-09