Re: TODO: GNU TLS

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: TODO: GNU TLS
Дата
Msg-id 20061228213255.GV24675@kenobi.snowman.net
обсуждение исходный текст
Ответ на Re: TODO: GNU TLS  (mark@mark.mielke.cc)
Список 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 по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: TODO: GNU TLS
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Dead Space Map for vacuum