Re: TODO: GNU TLS

* mark(at)mark(dot)mielke(dot)cc (mark(at)mark(dot)mielke(dot)cc) wrote:
> On Thu, Dec 28, 2006 at 02:48:56PM -0500, Stephen Frost wrote:
> > I disagree that the only way Postgres should support multiple
> > libraries for a given component is if they provide the same API- we
> > wouldn't have much in the way of authentication options if that was
> > really the case.
>
> I don't believe that was said. However, using two very different APIs
> for the exact same purpose, providing the exact same functionality
> would seem to require a business case. If fear of litigation over
> what seems to be a non-existent point is the only business case, the
> position deserves to be challenged.
>
> There are other elements that could be included in the business case.
> For example, the documentation for GNUTLS seems to be significantly
> better.

I havn't done serious comparisons of the two since the license issue
matters to me, honestly, so this can be taken with a grain of salt,
but...

OpenSSL has more features and some niceties like the TLS_CACERTDIR
(I've asked for this in GNUTLS, actually, so it might have it soon)
They can each be faster than the other in some instances
(I'm not sure which though, I've heard of 15% differences in each
direction depending on architecture though)
GNUTLS has a nicer/better API
GNUTLS has a smaller memory footprint
OpenSSL is working to get NIST certification/approval
(it had it, but then lost it for some reason and they're working to
get that fixed)
GNUTLS has better documentation

Actually, from a comparison done for libcurl (which supports both):

GnuTLS vs OpenSSL

While these two libraries offer similar features, they are not equal. Both
libraries have features the other one lacks. libcurl does not (yet) offer a
standardized stable ABI if you decide to switch from using libcurl-openssl to
libcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurl
and it has not been tested nor used very extensively, while the OpenSSL
equivalent code has been used and thus matured for more than seven (7) years.

GnuTLS
- LGPL licensened
- supports SRP
- lacks SSLv2 support
- lacks MD2 support (used by at least some CA certs)
- lacks the crypto functions libcurl uses for NTLM

OpenSSL
- Original BSD licensened
- lacks SRP
- supports SSLv2
- older and more widely used
- provides crypto functions libcurl uses for NTLM
- libcurl can do non-blocking connects with it in 7.15.4 and later

That was from May 15, 2006:
http://curl.mirrors.cyberservers.net/legal/distro-dilemma.html

Regarding SSLv2 support, the GNUTLS page has this:

Support for TLS 1.1, TLS 1.0 and SSL 3.0 protocols

* Since SSL 2.0 is insecure it is not supported.
* TLS 1.2 is supported in the experimental branch.

> I don't like fear mongering. It smells like FUD. :-)

While I didn't intend it as fear mongering I can understand that might
be the impression whenever licenses and possible license violations are
brought up. I don't know of anyone who's actually attempting to
prosecute this nor do I generally expect someone to in the future.
Even so though, it wouldn't be a PostgreSQL issue anyway but rather
an issue for someone distributing OpenSSL and some GPL application which
linked against it (ie: a distribution like Debian).

Thanks,

Stephen