On Fri, Aug 19, 2005 at 11:19:39PM +0200, Daniel Stenberg wrote:
> On Fri, 19 Aug 2005, Richard Atterer wrote:
> >The trick: Create your own "libcurl-ssldummy.so" version of OpenSSL. It
> >provides symbols for the entire OpenSSL API, but returns an error if any
> >function is called.
>
> If we add support for linking with both at once, then such a trick could
> easily be done by a packager of libcurl. I don't think we in this project
> need to do anything particular to support this. Other than perhaps make
> the code deal with such a situation in a suitable way.

Hm, I'm not so sure, I'd opt for this whole scheme to be implemented by
"upstream", not the distro packager.

The most important point is that upstream curl should provide a working
"curl-config" which supports the special "--no-openssl" switch (or whatever
mechanism).
Imagine the case where someone wants to compile a libcurl app on his own
Linux distro and then run the (dynamically linked) program on another
distro. The standard libcurl package is installed on both machines. If his
app is GPLed, he must be able to rely on libcurl-ssldummy.so being present
on both systems.
Also, the author of the GPLed app should be able to enforce the "no linking
to OpenSSL" by including the --no-openssl in his source code, so that
anyone who compiles from source automatically gets a correctly linked
binary.

[Incidentally, the above means that libcurl-ssldummy.so should _always_ be
compiled and installed alongside libcurl, even if neither OpenSSL nor
GnuTLS is used - I hope this thought is acceptable for you... :-/ An
explicit configure switch should be necessary for people who really don't
need the dummy lib.]

Another point in favour of doing this upstream is that otherwise, it just
won't happen. I hope I'm not sounding like a snobbish Debianite here ;),
but many distros just package things with a standard "./configure && make"
and only come back if there's a bug which actually affects user experience.
Additionally, some distros are rather indifferent WRT the subtleties of
open-source licenses. :-)

Finally, I also think a standardised libcurl-ssldummy.so is useful because
then libcurl itself can rely on the behaviour of the dummy lib. If a
packager creates "some dummy lib" just to keep the linker quiet, then any
attempt to use HTTPS from an app which was mistakenly linked with
-llibcurl-ssldummy will result in undefined behaviour, maybe even a crash.
OTOH, if libcurl detects libcurl-ssldummy.so, it can give back a nice error
message "HTTPS not supported".

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯