Let's drop support for NSS!

[Daniel Atallah]

On Fri, Sep 12, 2014 at 7:13 PM, Mark Doliner <mark at kingant.net> wrote:

> 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.
>


I agree with the sentiment that having multiple implementations is more
work and of questionable value at the moment.


> 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?
>


The situation with building NSS on Windows isn't exactly awesome right now
- it involves using the Microsoft compiler and quite a few hoops:
https://developer.pidgin.im/wiki/BuildingWinNSS

As long as GnuTLS is functional and reasonably maintained on Windows, there
shouldn't be a major technical problem using it instead of NSS.

I guess my gut is to prefer NSS over GnuTLS, but I don't have any real
analysis to back that up with either.

It's certainly true that some of the NSS documentation is less than stellar
- I know that I've dug through code to figure out how to do stuff.

GnuTLS may be more widely used in various smaller projects, but I believe
that NSS is more widely used by same class of end users as use Pidgin (e.g.
both Firefox and Chrome/Chromium use it) and there are a number of examples
where NSS has chosen to do things in such a way that reduces unnecessary
user impact (Kai's email contains one such example,
https://developer.pidgin.im/ticket/16172 is another).

I assume that we're talking about 3.0.0, and not 2.x.y?

-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20140916/65641a65/attachment-0001.html>