On Sun, Oct 27, 2013 at 01:36:39PM +0100, Daniel Stenberg wrote:
> I think we should instead do one of these:
>
> 1) add a new type that would return a pointer to an object where the
> object would be option-specific. So in this case it'd return a
> pointer to a curl_tlsinfo struct (and that struct would need to be
> kept in the curl easy handle).
>
> /* it would look like this */
> struct curl_tlsinfo *tlsinfop;
> curl_easy_getinfo(curl,
> CURLINFO_TLS_SESSION,
> &tlsinfop);
>
>
> 2) add a new type that would pass in a pointer to a struct where
> that struct is object specific, and libcurl would write the
> return-data into that struct.
> That would make the application "own" the memory that is written to.
>
> /* it would look like this */
> struct curl_tlsinfo tlsinfo;
> curl_easy_getinfo(curl,
> CURLINFO_TLS_SESSION,
> &tlsinfo);
>
> Opinions?

I'm worried about the potential danger of having the app/libcurl compiled
against an older version of the library but linked against a newer one, when
the SSL-library specific struct is different (larger) in the newer version than
the older. There is a danger of a buffer overflow in this case, which is
typically mitigated by macros in the low-level library function calls passing
in a version number or struct size into the function call that populates the
struct, or having the library do the allocation and just pass back a pointer.

The latter wouldn't be a problem either way here, but we have many SSL
libraries to support and I haven't looked at how they all handle this case. If
you push the struct allocation down to the application, then the macro
mitigation technique won't work, because the application isn't the one calling
the library to populate the struct. To allow that flexibility, I think that
libcurl should be the one to allocate the memory for this struct (for those
libraries that don't do it themselves).

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-10-27