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: Default to CURLSSLOPT_NATIVE_CA for curl --without-ca-bundle ?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 17 Oct 2023 16:02:57 +0200 (CEST)
On Tue, 17 Oct 2023, Jeroen Ooms via curl-library wrote:
> Perhaps it makes sense to enable CURLSSLOPT_NATIVE_CA by default for curl
> builds --without-ca-bundle? At least on Windows I think that makes sense
> (and perhaps is even what one would expect) when we build curl against
> openssl but without a bundle.
If you are up to doing a special build like with --without-ca-bundle then
you're doing "your own thing" and you side-step the defaults and the behaviors
we provide to libcurl users in general.
That is close to just patching curl yourself and adding custom code for
whatever conditions and logic you want. It is not default behavior and it is
not API nor ABI protected build options.
I'm fine with everyone doing those things for their own users and their own
situations, but I am personally less interested in discussions of what is the
most sensible in these custom-patch-cases. Because they are edge cases and
special. They are not the regular libcurl behavior.
We recently had a long discussion in issues and PRs about loading the system
CA store (or not) when --with-ca-fallback is used. I was and still am against
it.
I do not think curl should default to the system CA by default, since that
would break behavior. I don't think we should provide an environment variable
that makes curl load the system CA by default, because it seems a little too
cherry-picked and people have in past discussions been pretty firmly against
previous "change curl behavior if an environment variable is set" proposals.
Why don't you make sure you set CURLSSLOPT_NATIVE_CA yourself unconditionally
or based on an environment variable when libcurl is used?
Date: Tue, 17 Oct 2023 16:02:57 +0200 (CEST)
On Tue, 17 Oct 2023, Jeroen Ooms via curl-library wrote:
> Perhaps it makes sense to enable CURLSSLOPT_NATIVE_CA by default for curl
> builds --without-ca-bundle? At least on Windows I think that makes sense
> (and perhaps is even what one would expect) when we build curl against
> openssl but without a bundle.
If you are up to doing a special build like with --without-ca-bundle then
you're doing "your own thing" and you side-step the defaults and the behaviors
we provide to libcurl users in general.
That is close to just patching curl yourself and adding custom code for
whatever conditions and logic you want. It is not default behavior and it is
not API nor ABI protected build options.
I'm fine with everyone doing those things for their own users and their own
situations, but I am personally less interested in discussions of what is the
most sensible in these custom-patch-cases. Because they are edge cases and
special. They are not the regular libcurl behavior.
We recently had a long discussion in issues and PRs about loading the system
CA store (or not) when --with-ca-fallback is used. I was and still am against
it.
I do not think curl should default to the system CA by default, since that
would break behavior. I don't think we should provide an environment variable
that makes curl load the system CA by default, because it seems a little too
cherry-picked and people have in past discussions been pretty firmly against
previous "change curl behavior if an environment variable is set" proposals.
Why don't you make sure you set CURLSSLOPT_NATIVE_CA yourself unconditionally
or based on an environment variable when libcurl is used?
-- / 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/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-10-17