Hi Paul, I may have accidentally killed that while refactoring the TLS backend IO handling. Sorry about that.
I think we need a test case for that edge case. Kind Regards, Stefan > Am 27.01.2023 um 10:13 schrieb Paul Groke via curl-library > <curl-library@lists.haxx.se>: > > Hi, > > we noticed a change in behavior wrt. CURLOPT_SSL_VERIFYPEER and > CURLOPT_CAINFO_BLOB with libcurl 7.87.0. > > Our application always sets CURLOPT_CAINFO_BLOB to a non-null value, because > we never want to use any built-in default/system default certificate bundle > path. > If no CAs are configured for our software, we set CURLOPT_CAINFO_BLOB with a > non-null pointer to a `curl_blob` struct, which has `len` set to zero (and > `data` pointing to a null byte). > Additionally we set CURLOPT_SSL_VERIFYPEER to whatever our appliaction's > config requests. > > We often have the case where CURLOPT_CAINFO_BLOB is set to "empty string" as > described above, and CURLOPT_SSL_VERIFYPEER is set to 0. > > With previous libcurl versions, this used to work. Which to me makes sense. > We explicitly instruct libcurl to use an empty certificate list, but also > tell it to not verify certificates. So IMO there's no reason for a transfer > with such settings to fail because of a certificate-related error. > > With 7.87.0, the behavior changed: the transfer now fails with error > >> Problem with the SSL CA cert (path? access rights?). > > We link libcurl statically and have tests that cover this combination, so at > least for us this didn't break any existing installations. For new versions, > we can work around it by changing our code to clear/reset CURLOPT_CAINFO_BLOB > by setting a null pointer in case our verify peer option is set to "false". > > I still thought I should let you know, because this looks like an unintended > and also undesirable change to me. It could break applications with similar > usage of CURLOPT_CAINFO_BLOB + CURLOPT_SSL_VERIFYPEER, if they link libcurl > dynamically or don't have tests that cover this combination. > > My guess is that this was caused by the new certificate caching code, but we > didn't verify this hypothesis. > > Another thing that may be worth checking is setting CURLOPT_CAINFO or > CURLOPT_CAPATH to a non-existing path/"permission denied" path, while also > setting CURLOPT_SSL_VERIFYPEER=0. I wouldn't be surprised if this also > results in the same error. And if memory serves, this also used to work. > > Best regards, > Paul > -- > Unsubscribe: https://lists.haxx.se/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
