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