Hello!

Is it common that nobody responds in a timely fashion to patches sent to
this list? I'd really like to know if this patch is now going to
be accepted, or if we have to do something else to get access to SSL
certificates.

Thanks!

Christian

On 10/15/2013 03:26 PM, Christian Grothoff wrote:
> Hi!
>
> 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).
>
> I hope you like this more general evolution of the API. While I
> did test this using code very much like the one supplied in the
> commit message, I cannot say what happens during SSL connection
> shutdown --- again, the patch expects that if the SSL connection
> is shut down, the "use" flag is cleared by libcurl and/or the
> handle(s) are reset to NULL.
>
> I toyed with the idea of returning a 'union' with the precise
> types from the various SSL backends instead of returning a 'void *',
> but that would have tied the public curl API to the various SSL
> APIs, which would have been ugly, so I think 'void *' should do
> nicely for now.
>
> Happy hacking!
>
> Christian
>
> On 10/12/2013 11:55 PM, Daniel Stenberg wrote:
>> On Fri, 20 Sep 2013, Christian Grothoff wrote:
>>
>>> Here is another patch which adds the CURLINFO_GNUTLS_SESSION option to
>>> curl_easy_getinfo. It exposes the GnuTLS session to clients, which is
>>> useful if clients need to inspect certificate chains or other
>>> properties of the TLS connection. Naturally, the option only works if
>>> cURL was compiled with GnuTLS support (hence the GNUTLS in the name).
>>> This patch should be completely independent from my previous patch to
>>> support CURLINFO_CERTINFO with GnuTLS, and I think it is generally
>>> more useful as it allows applications to access certificates via the
>>> nice GnuTLS X509 APIs instead of having to parse the strings.
>>
>> Hi!
>>
>> I can see why this option can be handy. I don't really like opening up
>> the API for even more SSL-library specific things so I would prefer if
>> you can think of a way that can return this information in an even more
>> generic way that will include information for what SSL library the
>> handle concerns so that we don't end up having to add a new such option
>> for every SSL library we want to allow this "extraction" for.
>>
>> Also, I found the code needing some comments to explain what the loop
>> does and I'm also a bit concerned if this really works properly in all
>> cases, like even if the SSL connection was completely shutdown previous
>> to this curl_easy_getinfo() call. How much testing have you done on this?
>>
>>
>>
>> -------------------------------------------------------------------
>> List admin: http://cool.haxx.se/list/listinfo/curl-library
>> Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-10-21