Supporting more than one file is an interesting idea. This current single file restriction (except for OpenSSL which can have a directory of certs) is primarily because how the TLS libraries' APIs for doing certificate loading/verification. It could certainly be changed to support multiple files, but it would not be an inisignificant amount of work...Although I suppose one could come up with some use cases, isn't this exactly equivalent to concatenating the multiple files into one? If it's not convenient to do this externally to the application, this is easily done by the application with a tempfile - more easily than by libcurl due to lifetime considerations.
Such a crypto lib API limitation is something I was concerned would exist, and obviously requires such workarounds to support this use case. I agree that it makes sense to handle this inside the applications then, maybe with some support of libcurl by means of dedicated helper functions.
Can you query the path to the system CA certificate from libcurl reliably (e.g., using some dedicated function)? This would help a lot while adding this to an application. Ideally, the list generated by CURL_CHECK_CA_BUNDLE could be fetched as well. Both could be available from curl-config if a runtime function is too much overhead, but I think a function within libcurl would be the better solution.
By the way, some use cases of such a feature:- an application wants to extend the list with a self-signed certificate (e.g., to allow access to a private service which you cannot easily get a certificate for) - one wants to test some piece of code against a local server, but needs to make requests to third-party services on the Internet in the process (for instance, an OIDC login from a local test server using an external IdP)
Such a temp file will go away at exit, or if bigbundle is closed. (knowing when to close it is what might be tricky for libcurl, depending on when the TLS library is done with the file.)If the list is used more than once, creating the big bundle will be more efficient if done externally - even if libcurl tried to cache it, which would get messy.
True words. If it is not possible for libcurl to forward a list, then it's easier to move this process into the application, which passes the result libcurl for every request, and handles cleanup. An application could even cache on the filesystem this result if needed, for instance.
If there were enough use cases to justify it, I guess concatenating files into a tempfile could be a libcurl convenience function... it doesn't seem like a a lot of work either way.
As far as I can see, there are both files bundles and directory bundles, which would have to be concatenated. Creating a helper in libcurl would be beneficial to users so that they do not have to reimplement such code over and over again.
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
