libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] using other TLS libraries


From: Gauthier Haderer
Subject: Re: [libmicrohttpd] using other TLS libraries
Date: Wed, 25 Oct 2017 16:20:36 +0200

Hi Christan,

I'm not sure I really understand your point.

Regarding the detection of TLS backend's availability, one can use the function MHD_TLS_is_feature_supported() to test if a backend is present.

Of course, if MHD was built without support for a TLS backend, a client won't be able to use it unless it rebuilds MHD with support enabled. If your intent is to be able to add this support without the rebuild requirement, the only option is to add a TLS plugin mecanism. This would mean to publish the TLS API for plugin creators, basically "tls.h" plus plugin glue. And maybe deliver a few standard plugins for GnuTLS, OpenSSL, LibreSSL along with MHD or in another package.

Is this your idea?


Gauthier
 
Hi Gauthier,
I agree with Evgeny, good job. However, there is one (modest) change I
would like to see, which is that the TLS backend(s) should be loaded via
dlopen()/dlsym()/libltdl instead of hard-linked with MHD. That way, we
could actually have one "libmicrohttpd.so" binary installed and the
application can choose which (of the available, possibly none) of the
TLS backends it wants to use. If we do not do this, we end up with the
libcurl situation where you never know what TLS backend is available,
and if you do need a specific one, you're in hell.
That said, I think your refactoring is _exactly_ the right step in that
direction and it should take very little to go from there where I would
like to see this go.
Finally, while I agree with Evgeny that we want to see microhttpd2.h as
the new API, I disagree that this needs to wait for the microhttpd2-API
to be finalized or even implemented. I think if someone adds the
dlopen() capability to this, it could be merged rather quickly. The main
issue with dlopen() is the logic needed to reliably identify the
(relocatable) path to the plugin/shared library, which is _always_ very
messy IMO. (see gnunet/src/util/{os_installation.c,plugin.c} for how
I've hacked up solutions for this in the past).
Happy hacking!
Christian
On 10/18/2017 04:01 PM, Gauthier Haderer wrote:
> Hello,
>
> I recently made changes to abstract the TLS API needed by MHD. And I
> added support for OpenSSL. Could someone review my changes and tell me
> if this is something that could be part of an official version?
>
> You will find more information here:
> https://gnunet.org/bugs/view.php?id=4917#c12475
>
> Thank you,
>
>
> Gauthier

reply via email to

[Prev in Thread] Current Thread [Next in Thread]