* [EMAIL PROTECTED] ([EMAIL PROTECTED]) 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
signature.asc
Description: Digital signature
