Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
How to handle CA certificate bundles in portable application bundles (e.g., AppImages)?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: TheAssassin <theassassin_at_assassinate-you.net>
Date: Wed, 18 May 2022 20:05:41 +0200
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.
Received on 2022-05-18
Date: Wed, 18 May 2022 20:05:41 +0200
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.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature