On 10/15/2013 10:37 PM, Dan Fandrich wrote:
> On Tue, Oct 15, 2013 at 03:26:40PM +0200, Christian Grothoff wrote:
>> Here's an improved patch that makes this (presumably) SSL-backend
>> independent. I only tested it with GnuTLS though, and some SSL
>> backends are not supported by the patch. The patch would need to
>> be applied on top of the 2nd patch I sent (#2 and #3 are independent
>> of the first patch).
>
>> +/* info about the SSL library used, and the respective internal
>> + SSL handle that can be used to extract further information about
>> + the connection. Asked for with CURLINFO_TLS_SESSION. */
>> +struct curl_tlsinfo {
>> + curl_ssl_backend ssl_backend;
>> + void *internals;
>> +};
>
> I think it would be useful to add another field in this struct to allow
> handling version differences. If some back-end changes the format of its
> internal struct, or we need to add another piece of information in a future
> version of libcurl, it becomes tricky to do otherwise. We could always add a
> new enum value if that happens (e.g. CURLSSLBACKEND_GNUTLS_V3) but it's
> possible that different versions of some library could provide subtly
> incompatible struct formats without libcurl even being aware. Something as
> simple as adding a new field that's initialized to sizeof(struct
> ssl_library_type) or an SSL library version number of some sort (whichever
> makes most sense for each SSL back-end) might be good enough.

I don't quite see the need for that. It would not matter if gnutls or
OpenSSL
changes the internals of those structs, as the way they will be accessed by
applications is via the respective gnutls or OpenSSL API calls. Curl here
really just passes an opaque handle out to the application, and sane
application developers will continue to treat it as opaque. And if gnutls
were to subtly change its internals, how would curl know anyway?

And sure -- as you point out -- if we at some point were to change what
type
of opaque handle we return due to some significant change that we are
aware of,
we could always tag a version onto the enum. However, in general I think it
is sane to assume that the application has to link against the same version
of the SSL library as curl; otherwise, things are expected to break...

My 2 cents

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