https://bugs.documentfoundation.org/show_bug.cgi?id=164781
--- Comment #11 from Patrick (volunteer) <[email protected]> --- (In reply to Michael Stahl (allotropia) from comment #10) > LibreOffice has a document signature feature where the user can choose X509 > certificates from Mozilla products' profiles; on Windows, the system > certificate store is used, and the same could be done on MacOSX in theory. OK. So that would be a separate new feature for macOS and isn't related to this bug. Let me know if my understanding is incorrect. > this is entirely unrelated to any network connections, and the WebDAV/HTTP > UCP simply relies on libcurl to get the certificates. > > for Linux systems, libcurl is built with the OpenSSL backend, and we > configure that to read system certificates from various paths in > include/systools/opensslinit.hxx. I did some reading today and maybe I am missing something, but it sounds to me like we are only using cURL's "secure-transport" backend to validate the server certificates during SSL connection initialization. Let me know if there are other cases that cURL is using "secure-transport". But assuming the above, it appears that cURL can be built with the WolfSSL backend and that has support for the macOS Keychain. However, WolfSSL is GPL v2 so we can't include that in a Mac App Store version even if we put WolfSSL into a separate process due to Apple's App Store rules. So the next idea I found was to build cURL on macOS with the OpenSSL backend like Linux. But instead of looking for files and folders, maybe we can override the validation function and set CURLOPT_SSL_CTX_FUNCTION to our own custom function. Our custom function can then do validation of the server's X.509 certificates using native calls to the macOS Keychain: https://curl.se/libcurl/c/CURLOPT_SSL_CTX_FUNCTION.html I think our custom function would get the server's current certificate using SSL_CTX_get0_certificate(). Does this sound reasonable? I admit that I am far from an expert in any of this. But if this feasible, maybe it would also be a feasible replacement for "stunnel" on Windows? Any criticism of the above is welcome. -- You are receiving this mail because: You are the assignee for the bug.
