> > 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 > ... > > 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!
Oh my. I thought I need to return OpenSSL error code because current code base is doing so. https://github.com/curl/curl/blob/e97679a360dda4ea6188b09a145f73a2a84acedd/lib/vtls/openssl.c#L3325 > lerr = *certverifyresult = SSL_get_verify_result(BACKEND->handle); So I thought the field is backend dependent and I need to follow this by returning OpenSSL error code. But what you told above was completely opposite. Now I understand I should return CURLcode by defining a new code. Thanks. --- Basuke Suzuki PlayStation ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
