I have tested it; although there is connssl->io_need = CURL_SSL_IO_NEED_RECV; which can be removed, the tcp layer of adjust_pollset seems to readd it: [T530-0-0] [2/2] text [0-0] [TCP] adjust_pollset, !active, POLLIN fd=6 It may have to be worked around by eg. storing additional info in cf_socket_ctx?
On Wed, Aug 13, 2025 at 11:58 AM Stefan Eissing via curl-library < [email protected]> wrote: > > > > Am 13.08.2025 um 09:44 schrieb Daniel Stenberg via curl-library < > [email protected]>: > > > > On Wed, 13 Aug 2025, Ondra via curl-library wrote: > > > >> According to https://curl.se/libcurl/c/CURLOPT_SSL_CTX_FUNCTION.html, > “For OpenSSL, asynchronous certificate verification via > *SSL_set_retry_verify* is supported. (Added in 8.3.0 < > https://curl.se/ch/8.3.0.html>)”, so I have attempted to use this > approach; but I have found out, that although when I register my callback > via SSL_CTX_set_cert_verify_callback and then successfully call > SSL_set_retry_verify from it before returning from it indeed ensures that > next time the easy handle is processed by curl_multi, the verification > callback is called again, curl does not seem to do anything more. > > > > I think this is simply because this is not widely used nor understood > functionality. Looking at it now, I think it was unfortunate that we > accepted the change like that. Underdocumented and no test case that > verifies it. > > > > Maybe it is broken? Maybe it needs something else to work. > > > >> The issue is that while the asynchronous verification is pending, we > need for the easy handle to be inert, and when verification finishes, we > need to resume processing of that handle. Currently it seems that the easy > handle stays in previous state with regards of sockets scheduled on it’s > behalf by multi into the eventloop; since this socket can be (and in some > cases actually is) triggered (eg. readable) for the whole time, this will > lead to busy looping (as the cert verify callback is invoked again and > again and we have to use SSL_set_retry_verify every time). > > > > The question is really what else curl should do. I mean, if it doesn't > do that then when should it call the callback again? I'm afraid I don't > know how this asynch cert thing works in OpenSSL so I can't really tell. > > > >> Please what is the proper way how to handle this issue? > > > > I think it is pretty clear that this is unknown (to most of us). I think > you need to figure that out and possibly provide a patch that makes curl > work better with this. A test case and an example code would be excellent > and bring bonus points. > > We have the detection of a SSL_ERROR_WANT_RETRY_VERIFY and can in that > case suppress the connection socket for polling. The question is how would > the application tell libcurl that it is read to give it another try? That > seems to be mostly missing. > > - Stefan > > > > > -- > > > > / daniel.haxx.se || https://rock-solid.curl.dev-- > > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > > Etiquette: https://curl.se/mail/etiquette.html > > -- > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html >
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
