On Fri, 26 Oct 2018, [email protected] wrote:
This is the approach I personally prefer. Just make sure you document the
specific error codes and for what situations they are used, as detailed as
possible. This is the sort of thing that people soon might want for other
SSL backends as well and then we need detailed explanations to know how to
implement and use them there as well...
We have an internal review about this and the objection to this was that a
client expects OpenSSL error code and it is confusing to return CURLcode
into there. That is a reasonable point.
I think neither of those are suitable for CURLINFO_SSL_VERIFYRESULT. I think
there should be a new set of codes:
- The CURLcode enum doesn't have the necessary values to return, plus it would
be really weird
- We don't want to make the codes to depend on OpenSSL since other backends
might want to have more info as well
- We don't want to risk that OpenSSL changes them in a future when OpenSSL 3.0
comes
So counter proposal to this is that not defining new error code for
CURLcode, but using a OpenSSL error code instead. There is appropriate code
X509_V_ERR_HOSTNAME_MISMATCH defined for that purpose. This approach is
opposite way for common code base among ssl backend, but the error code
returned in the certverifyresult was already backend dependent. It seems a
right choice.
Every time the choice of TLS backend shines through and forces the application
to know about it or behave differently is a step in the wrong direction I
think.
[options cut out]
I'm sorry, but I thought you were going to leave the return codes as-is and
add values to CURLINFO_SSL_VERIFYRESULT for more detailed info - which wasn't
even among these options. Now I'm deeply confused!
--
/ daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
