On Wed, 27 Nov 2013, Steve Holme wrote:
Here are two more patches.
Many thanks for those - I will give them a complete review
tomorrow and hopefully push them soon after.
Both now pushed. The website has also updated to show the example code as
well:
Dear Steve,
Here are two more patches. #0001 makes the code more robust
against applications asking for info after the HTTP request
has been performed (which turns out to be too late, but
even if an application does that cURL should obviously not
deref NULL). #0002 adds an example for the new
Hi Christian,
On Wed, 27 Nov 2013, Christian Grothoff wrote:
Here are two more patches.
#0001 makes the code more robust against applications asking
for info after the HTTP request has been performed (which turns
out to be too late, but even if an application does that cURL should
On Thu, 21 Nov 2013, Steve Holme wrote:
I have now pushed it - after tidying up the commit comments, documentation
layout, etc... ;-)
I've also added it to a pending release notes commit as well.
Let's leave this now, but I just wanted to mention that we are now technically
in a feature
On Wed, 20 Nov 2013, Steve Holme wrote:
I'm happy to start pushing your work into the upcoming v7.34.0
release
Which version? The latest patch, or an earlier one?
The latest one - unless anyone else has any preference.
I have now pushed it - after tidying up the commit comments,
On Tue, 19 Nov 2013, Christian Grothoff wrote:
I understand what you were trying to achieve with the original patch
and that it kind of fits in with the CURLINFO_CERTINFO slist paradigm,
however, if you take a look at the certinfo.c example, it passes in
ptr.to_info rather than the
On 11/19/2013 09:44 PM, Steve Holme wrote:
Hi Christian,
On Tue, 19 Nov 2013, Steve Holme wrote:
Well, my first patch had the application own the memory.
Daniel didn't like that idea as too error-prone. So go figure.
I'll have a look at your original patch tomorrow, to see if we
are
On Sun, 17 Nov 2013, Christian Grothoff wrote:
Wouldn't option 2 be better as a) it is more in keeping with the
the existing API where the application owns the memory and 2)
application can then destroy it at its own leisure - potentially
isn't there a scenario where libcurl destroys the
On 11/18/2013 10:39 PM, Steve Holme wrote:
On Sun, 17 Nov 2013, Christian Grothoff wrote:
Wouldn't option 2 be better as a) it is more in keeping with the
the existing API where the application owns the memory and 2)
application can then destroy it at its own leisure - potentially
isn't
On Mon, 18 Nov 2013, Christian Grothoff wrote:
Exactly - neither one is great but I feel option 2 is the lesser of
two evils so to speak.
Well, my first patch had the application own the memory.
Daniel didn't like that idea as too error-prone. So go figure.
I'll have a look at your
On Tue, Nov 19, 2013 at 12:46:20AM +0100, Christian Grothoff wrote:
If we went down this route, then I can see a reason for having the backend
as a member variable but I would still recommend that we have a lightweight
CURLINFO_SSL_BACKEND option so an application can easily find out what
On 10/27/2013 01:36 PM, Daniel Stenberg wrote:
On Thu, 24 Oct 2013, Christian Grothoff wrote:
struct curl_tlsinfo tlsinfo;
union {
struct curl_tlsinfo *tlsinfo;
struct curl_slist *to_slist;
} gptr;
memset (tlsinfo, 0, sizeof (tlsinfo));
gptr.tlsinfo = tlsinfo;
On Sun, 17 Nov 2013, Christian Grothoff wrote:
I personally think (1) is cleaner. I've attached a patch that implements
your version (1) against current Git.
I may have misunderstood my quick read of the thread but I just wanted to
chirp up as I am wanting to add the something similar at some
On 11/17/2013 10:45 PM, Steve Holme wrote:
On Sun, 17 Nov 2013, Christian Grothoff wrote:
I personally think (1) is cleaner. I've attached a patch that implements
your version (1) against current Git.
I may have misunderstood my quick read of the thread but I just wanted to
chirp up as I
On Thu, 24 Oct 2013, Christian Grothoff wrote:
struct curl_tlsinfo tlsinfo;
union {
struct curl_tlsinfo *tlsinfo;
struct curl_slist *to_slist;
} gptr;
memset (tlsinfo, 0, sizeof (tlsinfo));
gptr.tlsinfo = tlsinfo;
curl_easy_getinfo (curl,
On Mon, 21 Oct 2013, Christian Grothoff wrote:
Sorry for being slow, but can you please squash this into a single
CURLINFO_TLS_SESSION patch for easier review? A patch for a patch is really
hard to read and comment on properly.
Sure, here you go.
This is now something pretty neat I'd say!
On 10/23/2013 10:44 PM, Daniel Stenberg wrote:
On Mon, 21 Oct 2013, Christian Grothoff wrote:
Sorry for being slow, but can you please squash this into a single
CURLINFO_TLS_SESSION patch for easier review? A patch for a patch is
really hard to read and comment on properly.
Sure, here you
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
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
On Mon, 21 Oct 2013, Christian Grothoff wrote:
First, stop the top-posting please.
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
On Tue, 15 Oct 2013, 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
On 10/21/2013 01:14 PM, Daniel Stenberg wrote:
On Mon, 21 Oct 2013, Christian Grothoff wrote:
First, stop the top-posting please.
Eh, I've always hit reply in Icedove, so this should not create top-posts.
Is it common that nobody responds in a timely fashion to patches sent
to this list?
On 10/21/2013 01:26 PM, Daniel Stenberg wrote:
On Tue, 15 Oct 2013, 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
So does anyone else on this list care about good security (ok, within the
limits set by TLS)? If so, please let Daniel know that access to certificate
data might be a good thing. If you don't care about security, please turn of
your computer now ;-).
We all (and especially Daniel) care about
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
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
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.
27 matches
Mail list logo
