Hello,
As you may know, I have recently triggered implementation of asynchronous openssl verification callback https://github.com/curl/curl/pull/18288 . I am using it to implement code similar to https://github.com/curl/curl/pull/17525 . It would be a great help to have this present under CURLSSLOPT_NATIVE_CA. I would however like to raise a potential issue: this pull request uses SecTrustEvaluateWithError which is a synchronous API; according to documentation ( https://developer.apple.com/documentation/security/sectrustevaluatewitherror(_:_:)?language=objc) it can be blocking (= download certificates from network; see last paragraph of the documentation). I must say I have never used the synchronous version, so I am not sure if this is an issue in practice; it is possible this option can be disabled. For use in multi where blocking is not allowed, this API is very problematic. There is an asynchronous API available, which causes callback to be invoked when verification succeeds ( https://developer.apple.com/documentation/security/sectrustevaluateasyncwitherror(_:_:_:)?language=objc); however this callback is invoked on a gcd queue, so there needs to be a mechanism how to switch to the multi’s thread, unpause the easy and trigger it’s processing. I am doing this in my code as I have classes wrapped around multi and easy; but as far as I can see there is no mechanism so far to do this via libcurl (eg. pipe() based fds; no idea about how to do this on Windows); additionally this asynchronicity potentially adds corner cases within implementation as the verification itself can not be canceled afaik. Plus only openssl supports the async cert verification. Frankly I do not know what is the correct approach to this problem for curl; for easy_perform this synchronous API will probably be sufficient. But please keep in mind that it is indeed possible to write completely non-blocking code with openssl on MacOS. Ondrej On Fri, Aug 22, 2025 at 11:04 PM Daniel Stenberg via curl-library < curl-library@lists.haxx.se> wrote: > On Fri, 22 Aug 2025, Demi Marie Obenour via curl-library wrote: > > > I think the best option would be to add support for Network.framework. > The > > preferred way to use Network.framework is with a user-mode network stack > > included in macOS and iOS, but it is also possible to use it with > sockets > > via a custom framer. Sockets have lower performance compared to the > > user-mode network stack included in Network.framework, though. > > I don't think that's possible. I used to, but after having seen attempts > to go > that route I'm no longer convinced. > > I'm not an expert on anything macOS so I might be wrong here, but based on > the > past PR for exactly that (https://github.com/curl/curl/pull/17509) it > turned > out that we would have to make quite enourmous sacrifices to make curl > work > with the Network.framework. Too big for us to accept really. We can't have > a > TLS backend that basically takes over and replaces half of everything curl > does (and done in a slightly different, unique, way), because it's going > to be > a pain to maintain, to document, to test and it would end up a frankencurl > no > one would like. > > Adding support for the native CA store seems like teeny tiny job in > comparison. > > -- > > / 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
