Hi

I've thought more about this issue as I've been following the ongoing "battle"
on the debian-devel mailing list.

Then it struck me that it really isn't a very good idea to provide _both_ SSL
layers for libcurl. The issue just isn't that simple.

I've already (before this outburst) been considering the ability to add
support for more SSL libraries now when I've abstracted it fairly well in the
libcurl internals.

AFAIK, both MatrixSSL and yaSSL are GPL licensed and available alternatives.
Possibly there are others too. I figure embedded systems developers "out
there" might become interested in this, since I believe these are in general
smaller than both OpenSSL and GnuTLS, while possibly less feature-rich - I
don't know the details.

If we would support more than two SSL libraries, it gets weird to offer
selecting from all of these at run-time and I find it unlikely that
application authors (would) want that.

The truth is probably that an author of an application that wants URL transfer
capabilities by libcurl either relies on

  (A) the generic SSL capabilities of libcurl without caring what SSL powers
      that provide it, or the author relies on

  (B) some certain features or powers of a specific lib

Let's take one step back again and look at the problem with sane pragmatic
eyes. (Assuming such exist.)

For the case A, it really doesn't matter what SSL lib libcurl is built with,
as it should "just work" and if it doesn't it is a bug that can and should be
fixed. (But if the bug isn't (easily) fixed, this quickly turns into a case B)
Of course we'll have a fixed ABI no matter what SSL lib is used[*].

For the case B, I'm back on square one and I cannot see how this can be
provided properly without having a unique libcurl library image for each SSL
library that it supports (and that are installed in the system).
libcurl-openssl.so, libcurl-gnutls.so, libcurl-matrixssl.so etc. (With
libcurl.so being the "default" install which could be a mere symlink to the
one of the specific libs you think is a proper default.)

The whole discussion on debian-devel assumes that there is no case B and that
everything that can make a case B is a bug that can and should be fixed so
there will be no case B in the long run, and thus everything is case A and
thus this whole reasoning is moot and unnecessary. I find that view a bit
idealistic. Perhaps I've been doing this too long! ;-)

[*] = There is at least two places in current libcurl that breaks the common
       ABI if you change SSL lib, and until they are sorted out we are most
       certainly seeing apps in case B.

       Place 1 - the multi-threaded mutex callbacks required by the underlying
       SSL libraries are not set nor offered by libcurl but you must use the
       SSL lib directly. Or in the case of GnuTLS, you must in case use one of
       GnuTLS's underlying libs directly. This is of course a bug that we
       should address.

       Place 2 - CURLOPT_SSL_CTX_FUNCTION is a callback that only is supported
       when built with an OpenSSL backend and it provides a pointer to a
       SSL_CTX pointer which is an OpenSSL type. I'm not sure how this is best
       treated in the GnuTLS case.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html