9cf47593542c6f5fb09e5c2651a56706e953d87d missed to update configure.ac/acinclude.m4

[michael-o]

I did this

When @bagder worked on 9cf4759 for GnuTLS he missed to update

curl/acinclude.m4

Lines 1255 to 1262 in b3570b3

	AC_MSG_RESULT([$with_ca_fallback])
	if test "x$with_ca_fallback" = "xyes"; then
	if test "x$OPENSSL_ENABLED" != "x1" -a "x$GNUTLS_ENABLED" != "x1"; then
	AC_MSG_ERROR([--with-ca-fallback only works with OpenSSL or GnuTLS])
	fi
	AC_DEFINE_UNQUOTED(CURL_CA_FALLBACK, 1, [define "1" to use built-in CA store of SSL library])
	fi
	])

.

This causes downstream issues at runtime https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288862

With a proper fix the build would have failed and downstream would have noticed much earlier. Please update acinclude.m4

I expected the following

Failure at configuration time.

curl/libcurl version

from git

operating system

FreeBSD 13

[bagder]

When @bagder worked on 9cf4759 for GnuTLS he missed to update

What did I miss to update?

[michael-o]

When @bagder worked on 9cf4759 for GnuTLS he missed to update

What did I miss to update?

--with-ca-fallback does not work wuth GnuTLS anymore, but is permited by to configure script. It fails silently at runtime. CURL_CA_FALLBACK is never tested at compile time. It now work for openssl only.

[bagder]

Can I ask why you are using this option?

[michael-o]

You mean the fallback? Yes, the underlying crypto framework knows best where to search for the system trust. Moreover, all ports on FreeBSD using OpenSSL use SSL_CTX_set_default_verify_paths(). OpenSSL is then configured accordingly. No needle to fiddle with every port. Ideally, this would rather be --with-native-ca.

[bagder]

this would rather be --with-native-ca.

We have traditionally considered "native" to be the CA stores that are tied to the system in the way macOS and Windows do it, so that there's a difference between using a CA cert bundle and the native.

On Linux, BSD etc when the system already uses a CA bundle, there's really no point in seeing it as native vs not native I think.

[michael-o]

this would rather be --with-native-ca.

We have traditionally considered "native" to be the CA stores that are tied to the system in the way macOS and Windows do it, so that there's a difference between using a CA cert bundle and the native.

On Linux, BSD etc when the system already uses a CA bundle, there's really no point in seeing it as native vs not native I think.

I don't disagree, but I'd even abstract from that. The actual on-disk format doesn't really matter as long as the crypto lib is able to access it. Consider it opaque to you. This suffices my understanding of "native". Both wolfSSL and GnuTLS do the same magic in the source code as OpenSSL does with the fallback. I see no reason why the openssl.c should not have "native" for non-Windows and "fallback" removed at some point.

[vszakats]

I've found it difficult to rely on this option. It's difficult to say what it
does, how it interacts with other options, and what it does depends
on a bunch of very sparsely (if at all) documented things: Which forks
support this? Which OpenSSL/fork versions? On which platforms?

Either way, PR for the same fix for CMake: #18365