Let's drop support for NSS!

[Luke Schierer]

On Sep 12, 2014, at 19:13 EDT, Mark Doliner <mark at kingant.net> wrote:

> I mentioned this a year and a half ago[1]. I'd like to drop support
> for using Mozilla NSS for TLS and standardize on GnuTLS (only in the
> master branch, not in release-2.x.y). We can keep TLS support
> pluginable so that Adium can continue to use OpenSSL (which we're
> generally ok with because we consider OpenSSL to be a part of OS X,
> and the GPL has a special inclusion for stuff that's considered part
> of the OS).
> 
> Why drop support for one of the TLS libraries?
> - It reduces the amount of code we have to maintain. One example:
> https://developer.pidgin.im/ticket/8061 wants us to tell NSS which
> versions of TLS to use and which ciphers to allow. I'd prefer if we
> didn't have to deal with stuff like that at all, but if we have to do
> it I'd prefer to only do it once (for either GnuTLS or NSS). There's
> also an issue on our private security mailing list. I won't go into
> detail here, but it affects both of our TLS plugins. I'd prefer if we
> only had to fix it in one place.
> - If anyone ever wanted to audit our TLS code, dropping support for
> one of the libraries significantly reduces the amount of code that
> would need to be audited.
> - I don't think there's any need to support two TLS libraries these
> days. Both NSS and GnuTLS exist basically everywhere.
> 
> Why prefer GnuTLS?
> Basically I trust it more. I've dabbled with both GnuTLS and NSS over
> the past few months. GnuTLS seems like the better project. Better
> documentation. Better API. More inertia.
> 
> Some examples:
> - Using SSL_CipherPrefSetDefault() to enable/disable ciphers is a
> pain. I prefer the GnuTLS approach where classes of ciphers can be
> enabled/disabled all at once.
> - The documentation for SSL_CipherPrefGetDefault is incorrect
> (copy/paste error from SSL_CipherPrefSetDefault) [2].
> - You must also set a "policy" before you can actually enable certain
> ciphers. These API feels clunky and antiquated to me. Also
> "NSS_SetDomesticPolicy" and "NSS_SetExportPolicy" are poor function
> names (they're US-centric).
> - These functions seemingly aren't documented at all:
> SSL_VersionRangeGetSupported(), SSL_VersionRangeGetDefault(),
> SSL_VersionRangeSetDefault().
> 
> The biggest problem I see with dropping NSS is that we currently use
> it in our Windows builds. But GnuTLS publishes Windows builds [3].
> Even if we can't use their Windows builds, seems promising that it's
> at least buildable on Windows. I haven't actually tried, though.
> 
> So, what do people think? Any objections? Are people ok with me
> ripping out NSS without having a solution for building on Windows?
> Would anyone else be able to tackle that?
> 
> --Mark
> 
> [1] https://pidgin.im/pipermail/devel/2013-February/022682.html
> [2] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/sslfnc.html#__SSL_CipherPrefGetDefault_
> [3] http://www.gnutls.org/download.html

The only objection I have is not a technical one.  Some users care about FIPS certifications, and some versions of NSS are in fact FIPS certified, while no version of GnuTLS are certified.  

Luke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pidgin.im/pipermail/devel/attachments/20140912/5292d791/attachment.sig>