libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] using other TLS libraries


From: Christian Grothoff
Subject: Re: [libmicrohttpd] using other TLS libraries
Date: Wed, 25 Oct 2017 19:41:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

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/
> 

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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