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.html
