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