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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
