On 01/05/2013 11:58 PM, Daniel Stenberg wrote:
> On Sat, 5 Jan 2013, Philip Montrowe wrote:
>
>> I was thinking more along the lines of adding an exit similar to CURLOPT_SSL_CTX_FUNCTION and
>> CURLOPT_SSL_CTX_DATA like so:
>
> I really prefer not to. Strongly.
indeed, since I am the culprit many years ago:
This was done when openssl was the only known backend (at least to me).

It has/had two purposes:
- setting some parameters to the openssl backend that could not be set by a curl option. like an
   additional verification exit to accept strange certs or else.
- way to set some curl option e.g. modify the URL at a very late point, e.g. when the certificate
was presented to the user.
   get a subjectInformation Access URL ...
>
> 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.
An approach would be to consider when a "user" of TLS should be able to interact in a handshake,
e.g. when a certificate is received etc, there should be a possibility to interact. A very low
level would be
to show the messages to a call back. One cannot expose backend internal representations. a level higher
would be to define a generic structure for encoded objects, like a json, perl, structure, one may
want to leave
this to language wrappers?

>
> 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?
>
Is this the get_info style idea? This may sufficient for information but not
if you want to modify things.
wouldn't it be necessary in this case to call this before and after
handshake messages from a call back.

One interesting callback could be to provide the certificate chain.

a double approach, like the very low level information callback in openssl
together with a more comfortable for a well identified cases like
getting an encoded cert may be a path to go.

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