libcurl + (NSS or openssl)

[Rich Megginson]

Dmitry Butskoy wrote:
> Matt_Domsch at Dell.com 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.
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.
>
> 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.
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.
>
> 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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/fbc06c0e/attachment.bin>