>> I really prefer not to. Strongly.

>> libcurl is 99% SSL library agnostic in its API and use. We try very hard to provide a single and stable API and ABI to applications so that they won't have to care about things like which SSL library libcurl uses.

>> CURLOPT_SSL_CTX_FUNCTION is an exception to that rule. It is unfortunate and it hurts users - but as we can't and won't remove it, we can certainly strive to not repeat that mistake and dig our hole even deeper.

>> Our task is to REDUCE the SSL-specific stuff from our API, not the other way around.

>> So, back to the subject at hand: I suggested a way that could offer a consistent API independently of the SSL backend. Is there a particular reason that wouldn't work?

OpenSSL provides about five items of information including the ciphername, description, number of bits, and number of "secret bits". Any general interface I think would have to provide all the information. I certainly have a mandate to report on the bit numbers.

But I know nothing about the 19 other providers aside from OpenSSL, so at this point I will have to bow out as I do not have the resource and time I would need to assist in this.

Thank you for your comments though.

Philip

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