Re: [libmicrohttpd] using other TLS libraries

[Christian Grothoff]

Yes, that is exactly what I would like to see, and AFAIK Evgeny has
started to hack on it.

-Christian

On 10/25/2017 04:20 PM, Gauthier Haderer wrote:
> 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/
>

signature.asc
Description: OpenPGP digital signature