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: Jeroen Ooms via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 17 Oct 2023 18:12:23 +0200
On Tue, Oct 17, 2023 at 4:02 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> 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?
Thanks for your thoughts. Indeed currently we handle this on our end,
but I thought this was such an obvious improvement, I should propose
this upstream! Clearly not everyone agrees :)
To me the situation seems a bit less edge-case than you portray it; on
a lot of systems there may not be a CA pem bundle, hence using the
system certs seems like a sensible default to build a portable
(lib)curl. But I see the backward-compatibility issue, so we can just
set patch this in our build, no problem at all.
Date: Tue, 17 Oct 2023 18:12:23 +0200
On Tue, Oct 17, 2023 at 4:02 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> 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?
Thanks for your thoughts. Indeed currently we handle this on our end,
but I thought this was such an obvious improvement, I should propose
this upstream! Clearly not everyone agrees :)
To me the situation seems a bit less edge-case than you portray it; on
a lot of systems there may not be a CA pem bundle, hence using the
system certs seems like a sensible default to build a portable
(lib)curl. But I see the backward-compatibility issue, so we can just
set patch this in our build, no problem at all.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-10-17