On Mon, Feb 06, 2017 at 09:49:05AM +0000, Matthew Whitehead wrote:
> This is a general discussion topic relating to a project we're currently using
> curl for. If I've used the wrong mailing list for that sort of discussion
> please let me know.

Nope, it's the right one.

> We build curl to use for HTTP & FTP support but we're now looking to extend
> this to use HTTPS/FTPS. The TLS provider has to be GSKit but for a few
> reasons we don't want to build with USE_GSKIT support. Reasons for not wanting
> to build with USE_GSKIT are:

That's a bit of an unusual requirement, I think.

> - We'd like control over which version of GSKit is loaded and where it is
> loaded from.
> - We don't require users to install GSKit so we'd like to have more control
> over the behaviour of curl if it tries to find the GSKit libraries and can't.
> - We already have libraries that manage the loading and unloading of GSKit,
> including handling the differences on various platforms.
> - The current implementation in gskit.c only supports OS400.
>
> Our current approach is to implement a generic, very thin curl TLS provider
> that we pass function pointers to before global_init. In the thin TLS provider
> we implement the various TLS functions (Curl_genssl_init, Curl_gensll_connect,
> Curl_genssl_cleanup etc.), each of which calls the associated function pointer,
> for example:
>
> int Curl_genssl_init(void)
> {
> return (sslProviderFPs.Curl_generic_ssl_init == NULL ?
> 1 : sslProviderFPs.Curl_generic_ssl_init());
> }
>
> The concrete implementation is in Curl_generic_ssl_init() {...} et al, which
> calls our existing libraries to load GSKit, fail cleanly if it isn't installed,
> and make the relevant GSKit calls if it is.
>
> This may seem a little convoluted but it's a solution that satisfies the
> requirements above. We're looking for feedback and general discussion on our
> approach and a view to whether this is something that could be contributed back
> to the project.

It is a bit convoluted. curl used a similar approach in the past to load the
LDAP libraries, and it's caused us trouble. Eventually, we ripped that out and
switched to the traditional link-time binding for LDAP. You'll have a long row
to hoe to try to convince this list that adding this kind of run-time linking
back into libcurl is a good idea.

It seems to me you could implement this without any changes to libcurl, though.
If you link your shim into its own static library (that exports a GSKit-like
API) then you could just point libcurl to the shim instead of the real GSKit.
The shim could do whatever it wants and libcurl wouldn't be the wiser.

>>> Dan
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-02-06