Dmitry Butskoy wrote:
Not in NSS itself, but there is this project as well - http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ - to assist in porting applications that use OpenSSL to use NSS. There are plans to provide support for MD4 as well. I don't think MD4 will be added to NSS, but perhaps to the ossl wrapper layer or to some other add-on layer.Matt_Domsch@xxxxxxxx wrote: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?You can, but it is obvious that a backward switch is very unlikely.Addon of some extra functionality to NSS seems questionable as well. Perhaps, in far future only. Unlike the OpenSSL and Gnutls, NSS seems more stable, more tested, more certificated -- ie. more conservative. Hence the support of some "corner" cases is not a primary goal.
Now that NSS has been adopted by the LSB - http://ldn.linuxfoundation.org/article/lsb-40-the-cryptography-strategy - there will likely be a lot more impetus to support other crypto. I think other countries have different crypto requirements outside of the usual SSLv3/TLSv1 algorithms and cipher suites, and I expect these will be supported by the NSS framework, if not directly supported by NSS.BTW, in some areas OpenSLL looks more perspective. For example, Russia have chosen other way for crypto in the state life -- so called GOST instead of RSA. OpenSSL will start to support it since 0.9.9, plans of NSS is unknown... As a result, the compulsion for NSS in Fedora can make its usage impossible in the state organisations of some countries.
Another issue is license compatibility. Whilst OpenSSL is "widely used", it can be considered as a "basic system application", hence programs may link with it anyway (due to some exception in GPL etc...). After the most of things will be switched to NSS, the OpenSSl itself will become "an optional" instead of "system basic". The correspond exception in GPL will not affect anymore, and the rest of GPL applications who still will use OpenSSL will become illegal.Just my thoughts... ~buc
<<attachment: smime.p7s>>
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
