RE: Fetching the detail of SSL Host verification failure
Date: Sat, 27 Oct 2018 16:27:55 +0200 (CEST)
On Fri, 26 Oct 2018, Basuke.Suzuki_at_sony.com 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
> 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
[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.htmlReceived on 2018-10-27