libcurl + (NSS or openssl)

[Matt_Domsch at Dell.com]

I understand the push behind getting as many packages to build against
nss as possible.  However, nss is not on feature parity with openssl at
this time.

I've run into two problems where this has bitten me.

First, libcurl being built against nss.  Nss does not provide some
functions which are necessary for NTLM authentication to succeed.  This
has defeatured the 'curl' application, rendering it useless in
environments where users are behind an NTLM-authenticating proxy.  This
bites me personally every day.  Yes, NTLM is based on MD4 which is
insecure. Nevertheless, choice of corporate proxy servers is often
beyond the reach of even the most senior Linux developers (aside from
changing jobs...)

Second, libcurl being built against nss.  OpenWSMAN has an eventing
capability, but this uses libcurl, which in turn would use a feature of
openssl. But as libcurl is not built against openssl, the eventing
capability at this point must be disabled in OpenWSMAN.  This capability
will be important to the sblim-* systems management software stack which
implements DMTF open standards.  I need to investigate further what the
source of the problem here is.

Arguably, one should discover the missing functionalty from nss, and
re-implement it so as to enable these functions.  However, as these
functions do work if linked against openssl, I would prefer to see the
expedient approach of linking libcurl against openssl again, and only
release with it linked against nss once it is at feature parity for the
functions used by software within Fedora.

Can I ask that libcurl be rebuilt against openssl instead of nss for the
time being?

Thanks,
Matt

--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux