These are relatively straightforward - the exception being c3ba162 - it would be great if you could sanity-check me on that @carlosmn

The docs for libcurl say we should be passing in a certinfo https://curl.haxx.se/libcurl/c/CURLINFO_CERTINFO.html although the example uses an union of both types https://curl.haxx.se/libcurl/c/certinfo.html so it looks like what we actually need is just a cast, because the example does imply we're getting a certinfo rather than a list.

WTF. The docs for curl_easy_getinfo say the opposite and that we should be using a struct_curl_slist *.

https://curl.haxx.se/libcurl/c/curl_easy_getinfo.html

The signature on that page says CURLcode curl_easy_getinfo(CURL *curl, CURLINFO info, ... ); and it matches what's in the headers in my system curl, so the compiler shouldn't care what we put it. I'm not sure where you're getting the list from.

I don't think that I understand your question. What list are you talking about? The curl_slist *? From the man page that I linked to:

The third argument MUST be a pointer to a long, a pointer to a char *, a pointer to a struct curl_slist * or a pointer to a double (as this documentation describes further down)

And this is enforced by https://github.com/curl/curl/blob/master/include/curl/typecheck-gcc.h#L111

It so happens that the struct curl_slist * is the first member of the struct curl_certinfo. And that internally curl happens to be setting that pointer to a struct curl_certinfo - which means of course we can safely use either, at least as long as the implementation remains as-is. My argument was that we shouldn't rely on an implementation detail, even though (of course) they will. Though this is quite a stupid situation to have two pieces of documentation that disagree with each other and an example that doesn't really make any sense (but of course works because it was written with knowledge of the internal state).

Anyway, I opened curl/curl#846 but I don't think that this really impacts us. We're walking the list, we don't actually need knowledge of the number of certs. We can treat that arg as a struct curl_slist * and be correct, honor half the documentation and the header in question, and that's what we should do.

But again, maybe I didn't understand your question.

curl has clarified that struct curl_certinfo * is indeed allowable, I dropped that commit changing it to a struct curl_slist *.