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.
Re: 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: Thu, 19 May 2022 02:24:15 +0200
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.)
Received on 2022-05-19
Date: Thu, 19 May 2022 02:24:15 +0200
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.)
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature