Re: curl reverts to openssl (but the story does not ends here)
On Aug 9 2005, Steve Langasek wrote:
(I'm not on the list, I read this response elsewhere and I handicraft this
> Even when libcurl works identically good using either library, OpenSSL and
> GnuTLS differ not only license-wise but they also have features of their
> own and bugs of their own. Limiting the libcurl offer to use only one of
> them will cause grief at some point in some camp(s), that's for sure.
Er, it's only SSL/TLS. The correct long-term answer to "they each have
bugs" is "fix the bugs in [libcurl's support for] GnuTLS", not "let the
users pick which set of bugs they like better".
I beg to differ. A lot.
1. It is not "only" SSL/TLS. For example, OpenSSL supports SSLv2 while
GnuTLS does not. GnuTLS supports SRP while OpenSSL does not.
If an author of an application that uses libcurl cares about either of
these differences, then that author might prefer one specific of these libs.
2. In the mail you replied to I was referring to bugs in the SSL/TLS
libraries, not the ones in libcurl. It is similar to (1) above, as the
authors of the libs might prioritize bugs differently or even disagree on
what a bug is or isn't etc.
3. There are application authors who _prefer_ the license of OpenSSL in
favour if the (L)GPL ones of GnuTLS (and its associated sub-libraries). So
even if the libs were identical, I think the license differences alone is
reason enough for two packages.
4. As these SSL libs provide completely different APIs they allow somewhat
different things to be done with different ease or even possibilities. I
don't find it unlikely that libcurl will offer different features to
applications depending on what underlying SSL lib that is used. This would
of course not be ideal or even wanted, but in real life it might still be
what we'll have.
There, I've stated my opinions. I'll refrain from further replying in this
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol