Hi folks,I am the maintainer of AppImageUpdate, which internally uses libcurl to talk to webservers. AppImageUpdate itself is distributed as an AppImage and as such can be used on almost all Linux distros.
The issue I am facing with this is that apparently, libcurl just hardcodes the path to the CA certificate bundle (e.g., the system-provided bundle). This behavior is problematic. An AppImage built on CentOS 7 using libcurl may expect the bundle to be in /etc/pki/tls/certs/ca-bundle.crt, however on Ubuntu we would have to look into /etc/ssl/certs/ca-certificates.crt. libcurl cannot load the bundle, and therefore the certificate validation fails. Please note that AppImageUpdate just serves as an example here. I also have seen this issue in an application which bundles libappimageupdate, and other applications using libcurl.
Is there some kind of "best practice" to make libcurl portable in that sense? I have several ideas in mind. First, one could just ship one's own bundle within the AppImage along with a specially built libcurl that uses this bundle (might require a patch to libcurl, though, to search for this path relative to the library location in order to make the resulting bundle relocatable). However, those may become outdated, and users may want to use, e.g., custom CA certificates they have added to their system bundle, and it is unexpected behavior and therefore a bad user experience if this just does not work with an AppImage version of an application. Therefore, I would prefer to use the system bundle.
To use the system bundle, I would like to propose the introduction of a CA certificate bundle "search path", which is just a set of potential paths libcurl can check one after another. libcurl could then just use the first path in the list which exists as a file on the system. This is what is used within some older AppImages using a patched libcurl binary. By providing this feature upstream, users of libcurl can just build their own up-to-date version using such a search path more easily. I do not think it would make sense to make this the default behavior. Also, I guess it does not make sense to include a default path with libcurl, since this requires maintenance and is most likely incomplete anyway (there is always some exotic Linux distro whose path is not included).
Another workaround I am using at the moment is to handle this on the application side, but this has several drawbacks (e.g., I cannot allow users to provide their own bundle in combination with the system bundle without additional complexity, since AFAIK libcurl accepts just one bundle path when making a request). I could imagine that (maybe in addition) to that search path, libcurl could allow developers to specify a list of bundles. That way, developers can use some off-the-shelf libcurl (for instance a pre-built distro binary), and can implement the "search for right path and pass the right bundle to libcurl" part inside their application's code. Other use cases include the use of an application-provided bundle in combination with the system bundle as well as a user-provided bundle.
I'm looking forward to the feedback already. I'm sure this is not the first time someone wants to use libcurl in portable, relocatable application bundles, but have not find a solution upstream yet. I'm willing to send in a prettier version of my current patch via pull request, of course, but first I'd like to see whether there are existing solutions I have not found previously, and which of the proposed features you'd consider for merge at all.
As a reference, this is the current search path in the patched libcurl (carefully curated, collected for years, still most likely incomplete):
/etc/ssl/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt /etc/ssl/cert.pem /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/cert.pem /etc/pki/tls/cacert.pem /usr/local/share/certs/ca-root-nss.crtP.S.: It's a bit of a shame that most Linux distros use custom paths for such resources. I guess some standardization might help there. But then again, that would be a long-term solution only anyway.
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
