Re: TODO: GNU TLS - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: TODO: GNU TLS |
Date | |
Msg-id | 20061228213255.GV24675@kenobi.snowman.net Whole thread Raw |
In response to | Re: TODO: GNU TLS (mark@mark.mielke.cc) |
List | pgsql-hackers |
* mark@mark.mielke.cc (mark@mark.mielke.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 mighthave 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 eachdirection 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 toget that fixed) GNUTLS has better documentation Actually, from a comparison done for libcurl (which supports both): GnuTLS vs OpenSSLWhile these two libraries offer similar features, they are not equal. Bothlibraries have features the otherone lacks. libcurl does not (yet) offer astandardized stable ABI if you decide to switch from using libcurl-openssltolibcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurland it has not been tested norused very extensively, while the OpenSSLequivalent 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 functionslibcurl 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
pgsql-hackers by date: