Description: libcurl is going to remove the backend we use at some point, so we will need to start using the libcurl that ships with macOS See thread here: https://curl.se/mail/lib-2025-01/0052.html Actual Results: Expected Results: Reproducible: Always User Profile Reset: Yes Additional Info:
Set to NEW
(In reply to Noel Grandin from comment #0) > See thread here: > https://curl.se/mail/lib-2025-01/0052.html I don't have any experience with using curl self-signed certificate so I did some searching to try and test if the curl that Apple bundles with macOS works with a certificate stored in the Keychain Access application. 1. I added a self-signed certificate using the steps in the following Apple support page and named the new certicate "My Cert": https://support.apple.com/en-ca/guide/keychain-access/kyca8916/mac 2. I then ran the following Terminal command: CURL_SSL_BACKEND=secure-transport /usr/bin/curl -v --cert 'My Cert' 'https://bugs.documentfoundation.org/' Unfortunately, the above command always fails with the following error: SSL: Can't find the certificate "My Cert" and its private key in the Keychain. Any ideas what I am doing wrong? Below is the curl version output on macOS Sequoia: /usr/bin/curl --version curl 8.7.1 (x86_64-apple-darwin24.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.63.0 Release-Date: 2024-03-27 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe UnixSockets
I found the cause of the failure I saw in comment #2. I recreated a "My Cert" certificate and this time checked the "Let me override defaults" in the Keychain Access dialog. Then I made sure the "SSL client" checkbox was checked. So now I have confirmed that at least macOS Sequoia's bundled libcurl has access to the Keychain Access certificate store. Is this the use case that the switch is meant to handle? Or are there other use cases?
One more detail: the curl command bundled with macOS Sequoia only supports --tlsv1.2. --tlsv1.3 will fail. So is being stuck at TLS v1.2 a problem?
(In reply to Patrick (volunteer) from comment #4) > One more detail: the curl command bundled with macOS Sequoia only supports > --tlsv1.2. --tlsv1.3 will fail. So is being stuck at TLS v1.2 a problem? This is weird, because this message: https://curl.se/mail/lib-2025-01/0062.html indicates that the macOS supports TLS1.3 But yes, being stuck at TLS1.2 is a problem, servers will stop supporting that at some point.
(In reply to Noel Grandin from comment #5) > indicates that the macOS supports TLS1.3 I think TLS 1.3 is limited to the LibreSSL backend but that does not appear to be able to read certificates in the Keychain Access application. Using the following command (note that no backend is specified): /usr/bin/curl -v --tlsv1.3 --cert 'My Cert' 'https://bugs.documentfoundation.org/' ...I get the following error: curl: (4) A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. Using the following command with Secure Transport: CURL_SSL_BACKEND=secure-transport /usr/bin/curl -v --tlsv1.3 --cert 'My Cert' 'https://bugs.documentfoundation.org/' ...works, but I see the following in the output: * Client certificate: My Cert * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > But yes, being stuck at TLS1.2 is a problem, servers will stop supporting > that at some point. So, from my limited testing, it looks like Secure Transport is stuck at TLS 1.2. Maybe switching to system libcurl may by us some time though until either the cURL developers or Apple implements some replacement for Secure Transport?
@Buovjaga do you know of any steps for using a certificate in the Keychain Access application within LibreOffice? I see Firefox and Thunderbird's certificate stores as well as GPG's store but I am not familiar with how users are using the Keychain Access certificates.
(In reply to Patrick (volunteer) from comment #7) > @Buovjaga do you know of any steps for using a certificate in the Keychain > Access application within LibreOffice? I see Firefox and Thunderbird's > certificate stores as well as GPG's store but I am not familiar with how > users are using the Keychain Access certificates. Let's ask Michael.
(In reply to Buovjaga from comment #8) > Let's ask Michael. While we're waiting for how to test this cURL functionality, what I can do is try setting up a simple Xcode project (I will upload it) that extracts the certificate for a particular name (I assume LibreOffice stores a name or hash?) and verifies that it is trusted. I think we can get an X.509 certicate from the macOS Keychain using the following: https://developer.apple.com/documentation/security/storing-a-der-encoded-x-509-certificate?language=objc ...and then verify that it is trusted using the following: https://developer.apple.com/documentation/security/sectrustevaluatewitherror(_:_:)?language=objc Here is where things get hazy for me: once we have a trusted X.509 certificate in memory, can we then pass the memory as a cURL option? I was looking at the following link and was thinking that we use it except that CURLOPT_SSL_VERIFYPEER would be set to 0 (since we already verified trust natively) and sslctx_function() wouldn't do anything and would just return CURLE_OK: https://curl.se/libcurl/c/CURLOPT_SSL_CTX_DATA.html Does that sound reasonable?
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. 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. my experience with MacOSX is limited to version 10.4, so you're probably not interested in it :)
(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.
at first glance, CURLOPT_SSL_CTX_FUNCTION might work to verify the certificates.
(In reply to Michael Stahl (allotropia) from comment #12) > at first glance, CURLOPT_SSL_CTX_FUNCTION might work to verify the > certificates. Is anyone looking at cURL on Windows? I am thinking of just trying to create a hacky, ugly patch (maybe for HTTPS connections?) just to test out this concept.
curl seems to be working fine on Windows? at least i haven't heard any complaints, and the STunnel thing seems to support TLS v1.3 so it doesn't meet upstream's criteria for removing backends.
OK. I'll add this bug to my "todo" list.
Unassigning myself as I am not going to have any time for this in the next few months.