Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On Thu, 2 Jun 2022, TheAssassin via curl-library wrote: One thing that would be nice to have as well is to compile in the value used in CURL_CA_BUNDLE_AUTODETECT and expose it via the API as well. This would allow applications to benefit from the list without having to maintain it themselves. You mean the list of paths in SEARCH_CA_BUNDLE_PATHS (in CMakeLists.txt) ? I'm not at all convinced it is libcurl's job to do that. I think it's one thing to try to find the default CA bundle when you build curl, it's a completely differerent thing to provide a (what will be perceived as) "blessed" list to users indicating that this is a complete or even a good way to go about this search. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
Stop On Wed, Jun 1, 2022, 7:34 PM TheAssassin via curl-library < curl-library@lists.haxx.se> wrote: > On 20.05.22 08:59, Daniel Stenberg via curl-library wrote:> Maybe this? > > > >https://github.com/curl/curl/pull/ > > Had a look at it. This covers part of what I need. Thanks! > > For my current use case (that is, zsync2/AppImageUpdate), I will just > copy the CA search path from the CMake/configure scripts for now, and > add the queried value if available, since I need to make this work. This > approach should work at least for a majority of distributions. I added > an SSL_CERT_FILE environment variable as a fallback, too. > > One thing that would be nice to have as well is to compile in the value > used in CURL_CA_BUNDLE_AUTODETECT and expose it via the API as well. > This would allow applications to benefit from the list without having to > maintain it themselves. > > Thanks everyone for the feedback and for the quick addition to libcurl! > -- > Unsubscribe: https://lists.haxx.se/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html > -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On 20.05.22 08:59, Daniel Stenberg via curl-library wrote:> Maybe this? https://github.com/curl/curl/pull/ Had a look at it. This covers part of what I need. Thanks! For my current use case (that is, zsync2/AppImageUpdate), I will just copy the CA search path from the CMake/configure scripts for now, and add the queried value if available, since I need to make this work. This approach should work at least for a majority of distributions. I added an SSL_CERT_FILE environment variable as a fallback, too. One thing that would be nice to have as well is to compile in the value used in CURL_CA_BUNDLE_AUTODETECT and expose it via the API as well. This would allow applications to benefit from the list without having to maintain it themselves. Thanks everyone for the feedback and for the quick addition to libcurl! OpenPGP_signature Description: OpenPGP digital signature -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On Thu, 26 May 2022, Timothe Litt wrote: Not clear why we need the CURL *handle to get just the (built-in) default strings. The handle is ignored for these INFO codes, right? curl_easy_getinfo() already exists and it works like this. I don't want to introduce a whole new function just for these and even if the easy handle doesn't mean anything for this use case, I don't want to complicated matters by documenting this exception. OTOH, if something was set for a handle by the user, it would be nice to get that - e.g. for the "generate C code" or "generate curl command" APIs. That's what I meant by "current bundle path for a handle". You could do both with one INFO code per string. We don't offer get methods for any other setopt, and I don't think we should start doing it now. Applications can easily just "remember" what they set options to on their own if they need that ability. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On 20-May-22 02:59, Daniel Stenberg wrote: On Thu, 19 May 2022, Timothe Litt via curl-library wrote: It would be nice to have a curl_easy_getinfo() along the lines of: |curl_easy_getinfo(CURL *curl, CURLINFO CURLINFO_CAINFO, char **path)| to get a string with the current bundle path for a handle Maybe this? https://github.com/curl/curl/pull/ Sorry to be slow responding; busy time here. Thanks for picking up on this. That's close to my idea, but: Not clear why we need the CURL *handle to get just the (built-in) default strings. The handle is ignored for these INFO codes, right? OTOH, if something was set for a handle by the user, it would be nice to get that - e.g. for the "generate C code" or "generate curl command" APIs. That's what I meant by "current bundle path for a handle". You could do both with one INFO code per string. So I thought the INFO calls might use a NULL handle to get the default string, and a valid handle to get whatever the string has been set to for that handle. If the handle-specific string is unset, the latter case could either return NULL or a pointer to the default. Sorry if that wasn't clear earlier. In any case, your PR does meet the minimum requirement of exposing the default string computed by the build (configure, cmake, etc.) Thanks for that. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On Thu, 19 May 2022, Timothe Litt via curl-library wrote: It would be nice to have a curl_easy_getinfo() along the lines of: |curl_easy_getinfo(CURL *curl, CURLINFO CURLINFO_CAINFO, char **path)| to get a string with the current bundle path for a handle Maybe this? https://github.com/curl/curl/pull/ -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
Can you query the path to the system CA certificate from libcurl
reliably (e.g., using some dedicated function)?
I don't think so. curl-config --configure may have "--with-ca-bundle=",
but if the bundle was defaulted by configure, I don't think it will be
listed.
Several limitations around the default bundle path have been noted:
It would be nice to have a curl_easy_getinfo() along the lines of:
|curl_easy_getinfo(CURL *curl, CURLINFO CURLINFO_CAINFO, char **path)|
to get a string with the current bundle path for a handle, and with the
'curl' argument NULL, the built-in library default. Neither is
currently accessible.
This would also make it possible to reset a curl handle to the default
bundle path, another recent request.
Optionally, having |curl_easy_setopt( curl, CURLOPT_CAINFO, NULL)| would
be a handy shortcut for
|char *default_bundle = NULL; CURLcode err;||
|
|if( (err = curl_easy_getopt( NULL, CURLINFO_CAINFO, &default_bundle))
== CURLE_OK ) ) {|
| err = curl_easy_setopt( NULL, CURLOPT_CAINFO, default_bundle ); /*
Or use a CURL handle instead of NULL to reset it */||
|
| free( default_bundle ); /* maybe */
|
| default_bundle = NULL;|
|} return err;||
|
As far as I can see, there are both files bundles and directory
bundles, which would have to be concatenated.
I don't see an efficient way to merge the (CAPATH) directories
containing certificates. These contain softlinks with the hash of
certificates pointing to an individual certificate file. The point is
to avoid reading all the certificates - when one is needed, the library
uses the hash to read just the one. This is only a win if there are a
LOT of certificates.
Neither libcurl nor the application knows what certs will be needed in
advance. So if you want to search several directories, you'd be left
with either reading all the certs in all the directories into a big
bundle file, or creating a temporary directory and copying all the links
from directories in your search list into the temporary directory. Then
specify that as a CURLOPT_CAPATH. Either way would be so expensive as
to defeat the optimization.
A middle ground would be to specify the larger directory as a CAPATH,
and merge the certs in the smaller into a big CAINFO bundle. This would
require application knowledge, and still wouldn't be very efficient.
As with CAINFO bundle merging, to make the cost worthwhile, the result
would have to be reused, and that will be more efficient if done externally.
Note that only a subset of TLS libraries support the CAPATH mechanism
For all these reasons, I think this is even lower priority than merging
CAINFO bundles...
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 19-May-22 06:07, TheAssassin via curl-library wrote:
On 19.05.22 11:43, Timothe Litt via curl-library wrote> On 19-May-22
04:38, Daniel Stenberg via curl-library wrote:
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 libcu
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On Thu, May 19, 2022 at 12:23:03PM +0200, TheAssassin via curl-library wrote: > I don't see why a user would add that path. If a user would compile libcurl > with /etc/motd as the main CA certificate bundle path at the moment, > unexpected behavior will occur as well. It is the job of the developer who > generates the libcurl binary to provide proper paths. I'm just using that as an example. /tmp/something would be even worse example. The developer is definitely responsible for choosing something sane. > Whether you support one bundle or multiple bundles doesn't make a big > difference. The proposed paths are all in read-only, root-writable > locations, as per the FHS. Only distributions which ignore this standard > could maybe be affected by such an issue. But then again, the existing > single CA bundle path may be writable as well. Using it in the way you describe should be fine. I'm just thinking about ways a naive developer could misuse the feature. Dan -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
Anything other than the standard OS-specific bundle is going to look magic to the user. For example, if the path were set to /etc/motd:/etc/pki/tls/certs/ca-bundle.crt then a file created at /etc/motd would magically (i.e. unexpectedly) cause TLS connections to stop working. I don't see why a user would add that path. If a user would compile libcurl with /etc/motd as the main CA certificate bundle path at the moment, unexpected behavior will occur as well. It is the job of the developer who generates the libcurl binary to provide proper paths. Yes, that's a contrived worst-case example, and if AppImage points it to an internal sandboxed path and documents it appropriately it shouldn't be a problem. AppImages are not sandboxed. Think of them as a slightly more advanced alternative to a self-extracting archive (the "extract" process is replaced by mounting the payload using FUSE). Also, I mentioned previously that I'd prefer not to ship a CA certificate bundle within the application bundle but use the system bundle. The most straightforward example is if the path included a world-writable location, then an attacker could place a bad certificate there and enable a MITM attack. Since there currently is no search within libcurl, there is currently no danger. Whether you support one bundle or multiple bundles doesn't make a big difference. The proposed paths are all in read-only, root-writable locations, as per the FHS. Only distributions which ignore this standard could maybe be affected by such an issue. But then again, the existing single CA bundle path may be writable as well. But then again you need to take into consideration that AppImages (or tarballs or any other relocatable bundle) are owned by the user who executes them. There is no security gain if a libcurl contained inside such a bundle would just check a single location, since an attacker could just replace that libcurl and rebuild the bundle. This feature doesn't open a new attack vector that is worse than that (which requires access to the host computer first anyway). OpenPGP_signature Description: OpenPGP digital signature -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On 19.05.22 11:43, Timothe Litt via curl-library wrote> On 19-May-22 04:38, Daniel Stenberg via curl-library wrote: 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
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On 19-May-22 04:38, Daniel Stenberg via curl-library wrote:
On Wed, 18 May 2022, TheAssassin via curl-library wrote:
I could imagine that (maybe in addition) to that search path, libcurl
could allow developers to specify a list of bundles.
I don't see how it makes any functional difference if the app makes
that search or if libcurl does it.
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.
Roughly:
bigbundle = tmpfile(); foreach bundle { open(); while read(bundle)
{write(bigbundle)}. close(); }; seek(0), curl_setopt(CURL_CAINFO,
/dev/fd/fileno(bigbundle)) ...
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.
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.
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
OpenPGP_signature
Description: OpenPGP digital signature
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On Wed, 18 May 2022, TheAssassin via curl-library wrote: I could imagine that (maybe in addition) to that search path, libcurl could allow developers to specify a list of bundles. I don't see how it makes any functional difference if the app makes that search or if libcurl does it. 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... -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On Thu, May 19, 2022 at 02:24:15AM +0200, TheAssassin via curl-library wrote: > On 18.05.22 22:57, Dan Fandrich via curl-library wrote: > > This sounds like it would become a source of problems, since the same > > application running on exactly the same OS would have different behaviour > > depending on whether a user-specified file is available in a magic location > > or > > not. > > What do you mean by user-specified file? The search path would be a > compile-time option, classic distro libs would not enable the option. > What do you mean by magic location? Anything other than the standard OS-specific bundle is going to look magic to the user. For example, if the path were set to /etc/motd:/etc/pki/tls/certs/ca-bundle.crt then a file created at /etc/motd would magically (i.e. unexpectedly) cause TLS connections to stop working. Yes, that's a contrived worst-case example, and if AppImage points it to an internal sandboxed path and documents it appropriately it shouldn't be a problem. > > There are security implications in setting up such a path. > > Could you please share your concerns? I have thought about this, too, but > couldn't come up with any problems. Note that the search path would be used > only by applications which come as an AppImage anyway. And the search within > libcurl is no way worse than a search within the application itself. The most straightforward example is if the path included a world-writable location, then an attacker could place a bad certificate there and enable a MITM attack. Since there currently is no search within libcurl, there is currently no danger. I'm probably more wary of this than I need to be, but if such a feature is added the implications need to be thoroughly thought through. Dan -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On 18.05.22 22:57, Dan Fandrich via curl-library wrote: In that case, the application can search for an appropriate bundle itself using whatever means it feels necessary and set it at run-time using CURLOPT_CAPATH, CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB. I now traced those options in the source code. My bad. I thought you could set those in addition to the default values already. This is apparently not the case. I still think there is some point in being able to use more than one chain at once. I can provide some real-world use cases if you want me to, but I guess this should be discussed separately. This sounds like it would become a source of problems, since the same application running on exactly the same OS would have different behaviour depending on whether a user-specified file is available in a magic location or not. What do you mean by user-specified file? The search path would be a compile-time option, classic distro libs would not enable the option. What do you mean by magic location? There are security implications in setting up such a path. Could you please share your concerns? I have thought about this, too, but couldn't come up with any problems. Note that the search path would be used only by applications which come as an AppImage anyway. And the search within libcurl is no way worse than a search within the application itself. AppImage is probably in the minority here in wanting this. I'm sure there are other portable applications facing such issues, AppImage is just one use case. I don't think AppImage competes with any of these other solutions anyway, since it has some unique traits it doesn't share with any of them. But on the other hand, I don't think that this is relevant to my feature proposal. The CURL_CHECK_CA_BUNDLE macro takes care of this in curl, It includes a few locations not in your list, like /etc/ssl/certs/ (CA path on SUSE), /usr/local/share/certs/ca-root-nss.crt (FreeBSD, MidnightBSD, so probably not relevant to AppImage), /usr/share/ssl/certs/ca-bundle.crt (old Redhat) and /usr/share/curl/curl-ca-bundle.crt (obsolete curl-specific bundle). Thanks for pointing me to that macro. I'll definitely check it out to extend the list with some of those in the future. For the record, (open)SUSE generate a bundle in /etc/ssl/ca-bundle.pem in addition to the directory. (And FreeBSD even received some AppImage support lately.) OpenPGP_signature Description: OpenPGP digital signature -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
On Wed, May 18, 2022 at 08:05:41PM +0200, TheAssassin via curl-library wrote: > 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. curl searches for an appropriate CA bundle at compile time and hard-codes the one it finds. This usually works fine, as curl shipped on CentOS 7 will have the right value for that OS, while curl shipped on OS X will have the right value for that. But, as you point out, this doesn't work well for a portable binary. In that case, the application can search for an appropriate bundle itself using whatever means it feels necessary and set it at run-time using CURLOPT_CAPATH, CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB. > 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 sounds like it would become a source of problems, since the same application running on exactly the same OS would have different behaviour depending on whether a user-specified file is available in a magic location or not. There are security implications in setting up such a path. > 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 don't remember hearing this as a feature request before, and curl is getting pretty old. I guess this is because other cross-platform environments (e.g., Flatpak, Snap, Docker, or using the system libcurl) solve the problem differently. AppImage is probably in the minority here in wanting this. It should be solvable without patching libcurl, though, using the method above. > 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.crt The CURL_CHECK_CA_BUNDLE macro takes care of this in curl, It includes a few locations not in your list, like /etc/ssl/certs/ (CA path on SUSE), /usr/local/share/certs/ca-root-nss.crt (FreeBSD, MidnightBSD, so probably not relevant to AppImage), /usr/share/ssl/certs/ca-bundle.crt (old Redhat) and /usr/share/curl/curl-ca-bundle.crt (obsolete curl-specific bundle). Dan -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
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.crt P.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
