Posted Mar 30, 2010 18:46 UTC (Tue) by drag (subscriber, #31333)
[Link]
Yet NSS is the crypto library used in the 389 Directory Server (aka Redhat Directory Server,
formally Fedora Directory Server; derived from the netstcape directory services...). So
somehow it's appropriate for that LDAP server even though the OpenLDAP folks do not like it.
NSS is also FIPS140-2 certified. The only other open source software that has gotten it is
OpenSSL. So that makes it appropirate for any sort of institution that has to work with the
USA federal government. Not terribly important for most people, but at least you know it's
been verified for correctness by third party experts and this certification is critically important
for companies like Redhat.
it's very mature library. It's been around for a long time. Supports hardware acceleration,
smart cards, and a bunch of other little things that OpenSSL does not. (and there, are, of
course things that OpenSSL supports that NSS does not)
The license is a lot better, also. NSS is triple licensed under the MPL, GPL, and LGPL giving it
superior license compatibility over OpenSSL or GnuTLS.
It also has very nice python bindings that Redhat put a lot of effort into. This allows you to use
Python with SSL support in GPL'd applications... which by default you technically cannot since
python's normal ssl stuff is OpenSSL derived.
There is some detail in the API design that is suppose to be superior for application
developers. Something about keeping the crypto aspect of things out of the hands of the
application developers... which is generally a good thing since app developers rarely get that
sort of thing correct. But I don't know enough to really understand everything and talk about it
much. Just what I've read in the past.
Personally, I feel if everybody decided to follow Fedora's example and standardize around a
NSS then we'd all be better off. Having lots of different crypto libraries is just asking for trouble
since it's surprisingly difficult to get crypto right.
But actually I do end up using OpenSSL a lot more then NSS because of the nice command
line client and ample online examples of OpenSSL usage. So I am not trying to knock the work
the OpenSSL folks have put into it.
OpenSSL 1.0.0 released
Posted Mar 30, 2010 18:54 UTC (Tue) by rahulsundaram (subscriber, #21946)
[Link]
Red Hat is leading this effort but it is worth noting that LSB is standardizing
on NSS as well
FIPS and GPL compatibility being two important driving factors.
OpenSSL 1.0.0 released
Posted Mar 31, 2010 15:14 UTC (Wed) by TRS-80 (subscriber, #1804)
[Link]
OpenLDAP ships client libraries as well as an LDAP server, and that's where the problem with NSS is. What happens when a program links against NSS and also links against libnss-ldap that's linked with NSS? NSS' lack of context support rules it out. The OpenLDAP server can also be an LDAP client through back-ldap and so has the same problem. It's not like the NSS developers don't realise this is a problem, they've defined functions to allow different contexts, but the functions are stubs that just return.