Allow choosing the SSL backend cURL uses (plus related patches)

This patch adds the Git side of that feature: by setting http.sslBackend to "openssl" or "schannel", Git for Windows can now choose the SSL backend at runtime.

[...]

Signed-off-by Johannes Schindelin <[email protected]>

---

http.c +4 -0

@@ -995,6 +1003,33 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
+#if LIBCURL_VERSION_NUM >= 0x073800
+       if (http_ssl_backend) {
+               const curl_ssl_backend **backends;
+               struct strbuf buf = STRBUF_INIT;

http.c +12 -0

+               case CURLSSLSET_NO_BACKENDS:
+                       die(_("Could not set SSL backend to '%s': "
+                             "cURL was built without SSL backends"),
+                           http_ssl_backend);
+               case CURLSSLSET_TOO_LATE:
+                       die(_("Could not set SSL backend to '%s': already set"),
+                           http_ssl_backend);
+               case CURLSSLSET_OK:
+                       break; /* Okay! */
+               }
+       }
+#endif

This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a remote server.

This is only supported in cURL 7.44 or later.

[...]

Signed-off-by Brendan Forster <[email protected]>

---

http.c +2 -0

+#endif
+       }

Note: an earlier iteration tried to use the config setting http.schannel.checkRevoke, but the http.* config settings can be limited to specific URLs via http.<url>.* (which would mistake schannel for a URL).

http.c +2 -0

+	}
+
 	if (http_proactive_auth)
 		init_curl_http_auth(result);

http.c static CURL *get_curl_handle(void) · line 828

Quoted 6 lines

http.c +6 -0

+#if LIBCURL_VERSION_NUM >= 0x072c00
+		curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
+#else
+		warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
+			"your curl version is too old (>= 7.44.0)");
+#endif

That ">=" is hard to grok. I think you meant it to be pronounced "requries at least", but that is not a common reading. People more commonly pronounce it "is greater than or equal to".

Quoted 4 lines · Brendan Forster via GitGitGadget

This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a remote server.

http.c static CURL *get_curl_handle(void) · line 824

Quoted 13 lines

This is only supported in cURL 7.44 or later.

[...]

Signed-off-by Brendan Forster <[email protected]>

---

http.c +7 -0

@@ -811,6 +818,16 @@ static CURL *get_curl_handle(void)
+       if (http_ssl_backend && !strcmp("schannel", http_ssl_backend) &&
+           !http_schannel_check_revoke) {
+#if LIBCURL_VERSION_NUM >= 0x072c00
+               curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
+#else
+               warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
+                       "your curl version is too old (>= 7.44.0)");

This message is confusing. If your curl is too old, shouldn't the ">=" be a "<"?

Quoted 3 lines

http.c +2 -0

+#endif
+       }

Quoted 4 lines · Brendan Forster via GitGitGadget

Note: an earlier iteration tried to use the config setting http.schannel.checkRevoke, but the http.* config settings can be limited to specific URLs via http.<url>.* (which would mistake schannel for a URL).

Yeah, "http.schannel.anything" would not work, but is this note relevant here? As far as the git development community as a whole is concerned, this is the first iteration of the patch we see and review.

In any case, you can use "http.<url>.$variable" to say "I want the http.$variable to be in effect but only when I am talking to <url>". Does it make sense for this new variable, too? That is, does it benefit the users to be able to do something like this?

[http] schannelCheckRevoke = no
[http "https://microsoft.com/"] schannelCheckRevoke = yes

I am guessing that the answer is yes.

I guess the same comment applies to the previous step, but I suspect that the code structure may not allow us to switch the SSL backend so late in the game (e.g. "when talking to microsoft, use schannel, but when talking to github, use openssl").

http.c static CURL *get_curl_handle(void) · line 828

Quoted 6 lines

http.c +6 -0

+#if LIBCURL_VERSION_NUM >= 0x072c00
+		curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
+#else
+		warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
+			"your curl version is too old (>= 7.44.0)");
+#endif

That ">=" is hard to grok. I think you meant it to be pronounced "requries at least", but that is not a common reading. People more commonly pronounce it "is greater than or equal to".

Quoted 5 lines

http.c +2 -0

+	}
+
 	if (http_proactive_auth)
 		init_curl_http_auth(result);

Quoted 10 lines · Junio C Hamano

http.c static CURL *get_curl_handle(void) · line 828

Quoted 6 lines

http.c +6 -0

+#if LIBCURL_VERSION_NUM >= 0x072c00
+		curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
+#else
+		warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
+			"your curl version is too old (>= 7.44.0)");
+#endif

That ">=" is hard to grok. I think you meant it to be pronounced "requries at least", but that is not a common reading. People more commonly pronounce it "is greater than or equal to".

This seemed oddly familiar:

https://public-inbox.org/git/[email protected]/

Since this one is clearly copied from there, it may be worth fixing the original.

Quoted 6 lines

Quoted 3 lines

That ">=" is hard to grok. I think you meant it to be pronounced "requries at least", but that is not a common reading. People more commonly pronounce it "is greater than or equal to".

This seemed oddly familiar:

Quoted 4 lines

https://public-inbox.org/git/[email protected]/

Since this one is clearly copied from there, it may be worth fixing the original.

Good memory. I just integrated the patch here. It was not signed off, but it is too obvious to be protected under copyright, so I re-did it, adding a nice commit message.

Quoted 9 lines

In any case, you can use "http.<url>.$variable" to say "I want the http.$variable to be in effect but only when I am talking to <url>". Does it make sense for this new variable, too? That is, does it benefit the users to be able to do something like this?

[http] schannelCheckRevoke = no
[http "https://microsoft.com/"] schannelCheckRevoke = yes

I am guessing that the answer is yes.

Frankly, I do not know. Does it hurt, though?

Quoted 4 lines

I guess the same comment applies to the previous step, but I suspect that the code structure may not allow us to switch the SSL backend so late in the game (e.g. "when talking to microsoft, use schannel, but when talking to github, use openssl").

Crucially, this fails. The short version is: this is good! Because it means that Git used the OpenSSL backend, as clearly intended.

<skip if="uninterested in the details">
Why does it fail?
...
</skip>

Quoted 4 lines · Brendan Forster via GitGitGadget

This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a remote server.

http.c static CURL *get_curl_handle(void) · line 824

Quoted 13 lines

This is only supported in cURL 7.44 or later.

[...]

Signed-off-by Brendan Forster <[email protected]>

---

http.c +7 -0

@@ -811,6 +818,16 @@ static CURL *get_curl_handle(void)
+       if (http_ssl_backend && !strcmp("schannel", http_ssl_backend) &&
+           !http_schannel_check_revoke) {
+#if LIBCURL_VERSION_NUM >= 0x072c00
+               curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
+#else
+               warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
+                       "your curl version is too old (>= 7.44.0)");

This message is confusing. If your curl is too old, shouldn't the ">=" be a "<"?

I have a clean-up suggestion related to this but is orthogonal to this three-patch series (after the fix-up is applied, anyway), which I'll be sending out separately.

When a requested feature cannot be activated because the version of cURL library used to build Git with is too old, most of the codepaths give a warning like "$Feature is not supported with cURL < $Version", marked for l10n. A few of them, however, did not follow that pattern and said things like "$Feature is not activated, your curl version is too old (>= $Version)", and without marking them for l10n.

Update these to match the style of the majority of warnings and mark them for l10n.

Quoted 6 lines · Eric Sunshine

Quoted 4 lines · Brendan Forster via GitGitGadget

This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a remote server.

Quoted 15 lines

http.c static CURL *get_curl_handle(void) · line 824

Quoted 13 lines

This is only supported in cURL 7.44 or later.

[...]

Signed-off-by Brendan Forster <[email protected]>

---

http.c +7 -0

@@ -811,6 +818,16 @@ static CURL *get_curl_handle(void)
+       if (http_ssl_backend && !strcmp("schannel", http_ssl_backend) &&
+           !http_schannel_check_revoke) {
+#if LIBCURL_VERSION_NUM >= 0x072c00
+               curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
+#else
+               warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
+                       "your curl version is too old (>= 7.44.0)");

This message is confusing. If your curl is too old, shouldn't the ">=" be a "<"?

I do not think I saw any update to correct this, and worse yet I do not offhand recall if there was any other issue raised on the series.

So assuming that this is the only remaining one, I'll squash the following to step 2/3 of this three-patch series and plan to merge it down to 'next' in the coming few days.

I have a clean-up suggestion related to this but is orthogonal to this three-patch series (after the fix-up is applied, anyway), which I'll be sending out separately.

Thanks.

 http.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

http.c +1 -1

index 0ebf8f77a6..43e75ac583 100644
@@ -835,7 +835,7 @@ static CURL *get_curl_handle(void)
 		curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
 #else
 		warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
-			"your curl version is too old (>= 7.44.0)");
+			"your curl version is too old (< 7.44.0)");
 #endif
 	}
 

Signature · 1 line

2.19.1-542-gc4df23f792

Quoted 8 lines · Johannes Schindelin

Quoted 8 lines

In any case, you can use "http.<url>.$variable" to say "I want the http.$variable to be in effect but only when I am talking to <url>". Does it make sense for this new variable, too? That is, does it benefit the users to be able to do something like this?

[http] schannelCheckRevoke = no
[http "https://microsoft.com/"] schannelCheckRevoke = yes

Quoted 3 lines

Quoted 1 line

I am guessing that the answer is yes.

Frankly, I do not know. Does it hurt, though?

I did not and I do not think it would. I was wondering if the ability to be able to specify these per destination is something very useful and deserves to be called out in the doc, together with
...

Quoted 4 lines

Quoted 4 lines

I guess the same comment applies to the previous step, but I suspect that the code structure may not allow us to switch the SSL backend so late in the game (e.g. "when talking to microsoft, use schannel, but when talking to github, use openssl").

... this bit.

Quoted 3 lines

Crucially, this fails. The short version is: this is good! Because it means that Git used the OpenSSL backend, as clearly intended.

Quoted 4 lines

<skip if="uninterested in the details">
Why does it fail?
...
</skip>

So there may still be some polishing needed, but as long as people are not using the "per destination" thing, the code is already good? That is something we may want to document.

Thanks.

When a requested feature cannot be activated because the version of cURL library used to build Git with is too old, most of the codepaths give a warning like "$Feature is not supported with cURL < $Version", marked for l10n. A few of them, however, did not follow that pattern and said things like "$Feature is not activated, your curl version is too old (>= $Version)", and without marking them for l10n.

Update these to match the style of the majority of warnings and mark them for l10n.

Signed-off-by Junio C Hamano <[email protected]>

---

Quoted 4 lines

I have a clean-up suggestion related to this but is orthogonal to this three-patch series (after the fix-up is applied, anyway), which I'll be sending out separately.

So, here it is.

 http.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

http.c +2 -4

index 43e75ac583..2214100e3b 100644
@@ -834,8 +834,7 @@ static CURL *get_curl_handle(void)
 #if LIBCURL_VERSION_NUM >= 0x072c00
 		curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
 #else
-		warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
-			"your curl version is too old (< 7.44.0)");
+		warning(_("CURLSSLOPT_NO_REVOKE not suported with cURL < 7.44.0"));
 #endif
 	}
 

@@ -908,8 +907,7 @@ static CURL *get_curl_handle(void)
 	curl_easy_setopt(result, CURLOPT_PROTOCOLS,
 			 get_curl_allowed_protocols(-1));
 #else
-	warning("protocol restrictions not applied to curl redirects because\n"
-		"your curl version is too old (>= 7.19.4)");
+	warning(_("Protocol restrictions not supported with cURL < 7.19.4"));
 #endif
 	if (getenv("GIT_CURL_VERBOSE"))
 		curl_easy_setopt(result, CURLOPT_VERBOSE, 1L);

Signature · 1 line

2.19.1-542-gc4df23f792

Quoted 7 lines · Junio C Hamano

When a requested feature cannot be activated because the version of cURL library used to build Git with is too old, most of the codepaths give a warning like "$Feature is not supported with cURL < $Version", marked for l10n. A few of them, however, did not follow that pattern and said things like "$Feature is not activated, your curl version is too old (>= $Version)", and without marking them for l10n.

Quoted 5 lines

Update these to match the style of the majority of warnings and mark them for l10n.

Signed-off-by Junio C Hamano <[email protected]>

---

I like this patch better than the one I had prepared for v2, so I dropped it again, and "hit the Submit button".

Quoted 4 lines

I did not and I do not think it would. I was wondering if the ability to be able to specify these per destination is something very useful and deserves to be called out in the doc, together with
...

I do not think that it needs to be called out specifically in the docs. It is just yet another http.* setting that can be overridden per-URL. It would be different if it had not worked.

From: Johannes Schindelin <[email protected]>

As of version 7.56.0, curl supports being compiled with multiple SSL backends.

This patch adds the Git side of that feature: by setting http.sslBackend to "openssl" or "schannel", Git for Windows can now choose the SSL backend at runtime.

This comes in handy on Windows because Secure Channel ("schannel") is the native solution, accessing the Windows Credential Store, thereby allowing for enterprise-wide management of certificates. For historical reasons, Git for Windows needs to support OpenSSL still, as it has previously been the only supported SSL backend in Git for Windows for almost a decade.

The patch has been carried in Git for Windows for over a year, and is considered mature.

Signed-off-by Johannes Schindelin <[email protected]>

---
 Documentation/config.txt |  5 +++++
 http.c                   | 35 +++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+)

Documentation/config.txt +5 -0

index 154683321..7d38f0bf1 100644
@@ -1984,6 +1984,11 @@ http.sslCAPath::
 	with when fetching or pushing over HTTPS. Can be overridden
 	by the `GIT_SSL_CAPATH` environment variable.
 
+http.sslBackend::
+	Name of the SSL backend to use (e.g. "openssl" or "schannel").
+	This option is ignored if cURL lacks support for choosing the SSL
+	backend at runtime.
+
 http.pinnedpubkey::
 	Public key of the https service. It may either be the filename of
 	a PEM or DER encoded public key file or a string starting with

http.c +27 -0

index 98ff12258..7fb37a061 100644
@@ -155,6 +155,8 @@ static struct active_request_slot *active_queue_head;
 
 static char *cached_accept_language;
 
+static char *http_ssl_backend;
+
 size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
 {
 	size_t size = eltsize * nmemb;

@@ -302,6 +304,12 @@ static int http_options(const char *var, const char *value, void *cb)
 		curl_ssl_try = git_config_bool(var, value);
 		return 0;
 	}
+	if (!strcmp("http.sslbackend", var)) {
+		free(http_ssl_backend);
+		http_ssl_backend = xstrdup_or_null(value);
+		return 0;
+	}
+
 	if (!strcmp("http.minsessions", var)) {
 		min_curl_sessions = git_config_int(var, value);
 #ifndef USE_CURL_MULTI

@@ -995,6 +1003,33 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
 	git_config(urlmatch_config_entry, &config);
 	free(normalized_url);
 
+#if LIBCURL_VERSION_NUM >= 0x073800
+	if (http_ssl_backend) {
+		const curl_ssl_backend **backends;
+		struct strbuf buf = STRBUF_INIT;
+		int i;
+
+		switch (curl_global_sslset(-1, http_ssl_backend, &backends)) {
+		case CURLSSLSET_UNKNOWN_BACKEND:
+			strbuf_addf(&buf, _("Unsupported SSL backend '%s'. "
+					    "Supported SSL backends:"),
+					    http_ssl_backend);
+			for (i = 0; backends[i]; i++)
+				strbuf_addf(&buf, "\n\t%s", backends[i]->name);
+			die("%s", buf.buf);
+		case CURLSSLSET_NO_BACKENDS:
+			die(_("Could not set SSL backend to '%s': "
+			      "cURL was built without SSL backends"),
+			    http_ssl_backend);
+		case CURLSSLSET_TOO_LATE:

Quoted 96 lines · Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

As of version 7.56.0, curl supports being compiled with multiple SSL backends.

This patch adds the Git side of that feature: by setting http.sslBackend to "openssl" or "schannel", Git for Windows can now choose the SSL backend at runtime.

This comes in handy on Windows because Secure Channel ("schannel") is the native solution, accessing the Windows Credential Store, thereby allowing for enterprise-wide management of certificates. For historical reasons, Git for Windows needs to support OpenSSL still, as it has previously been the only supported SSL backend in Git for Windows for almost a decade.

The patch has been carried in Git for Windows for over a year, and is considered mature.

Signed-off-by Johannes Schindelin <[email protected]>

---
 Documentation/config.txt |  5 +++++
 http.c                   | 35 +++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+)

Documentation/config.txt +5 -0

index 154683321..7d38f0bf1 100644
@@ -1984,6 +1984,11 @@ http.sslCAPath::
 	with when fetching or pushing over HTTPS. Can be overridden
 	by the `GIT_SSL_CAPATH` environment variable.
 
+http.sslBackend::
+	Name of the SSL backend to use (e.g. "openssl" or "schannel").
+	This option is ignored if cURL lacks support for choosing the SSL
+	backend at runtime.
+
 http.pinnedpubkey::
 	Public key of the https service. It may either be the filename of
 	a PEM or DER encoded public key file or a string starting with

http.c +33 -0

index 98ff12258..7fb37a061 100644
@@ -155,6 +155,8 @@ static struct active_request_slot *active_queue_head;
 
 static char *cached_accept_language;
 
+static char *http_ssl_backend;
+
 size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
 {
 	size_t size = eltsize * nmemb;

@@ -302,6 +304,12 @@ static int http_options(const char *var, const char *value, void *cb)
 		curl_ssl_try = git_config_bool(var, value);
 		return 0;
 	}
+	if (!strcmp("http.sslbackend", var)) {
+		free(http_ssl_backend);
+		http_ssl_backend = xstrdup_or_null(value);
+		return 0;
+	}
+
 	if (!strcmp("http.minsessions", var)) {
 		min_curl_sessions = git_config_int(var, value);
 #ifndef USE_CURL_MULTI

@@ -995,6 +1003,33 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
 	git_config(urlmatch_config_entry, &config);
 	free(normalized_url);
 
+#if LIBCURL_VERSION_NUM >= 0x073800
+	if (http_ssl_backend) {
+		const curl_ssl_backend **backends;
+		struct strbuf buf = STRBUF_INIT;
+		int i;
+
+		switch (curl_global_sslset(-1, http_ssl_backend, &backends)) {
+		case CURLSSLSET_UNKNOWN_BACKEND:
+			strbuf_addf(&buf, _("Unsupported SSL backend '%s'. "
+					    "Supported SSL backends:"),
+					    http_ssl_backend);
+			for (i = 0; backends[i]; i++)
+				strbuf_addf(&buf, "\n\t%s", backends[i]->name);
+			die("%s", buf.buf);
+		case CURLSSLSET_NO_BACKENDS:
+			die(_("Could not set SSL backend to '%s': "
+			      "cURL was built without SSL backends"),
+			    http_ssl_backend);
+		case CURLSSLSET_TOO_LATE:
+			die(_("Could not set SSL backend to '%s': already set"),
+			    http_ssl_backend);
+		case CURLSSLSET_OK:
+			break; /* Okay! */
+		}
+	}

http.c void http_init(struct remote *remote, const char *url, int proactive_auth) · line 1034

Quoted 4 lines

http.c +2 -0

+#endif
+
 	if (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)
 		die("curl_global_init failed");

Here's someone who upgraded to 2.20 on Arch linux & started getting "Could not set..." errors because of this change:
https://www.reddit.com/r/git/comments/a5ne5v/git_fatal_could_not_set_ssl_backend_to_openssl/

I don't know the context well enough, but is there perhaps enough info here so we could give a better error message, e.g. "don't set xyz twice in your config", or just emit a warning?

Quoted 98 lines · Ævar Arnfjörð Bjarmason

Quoted 96 lines · Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

As of version 7.56.0, curl supports being compiled with multiple SSL backends.

This patch adds the Git side of that feature: by setting http.sslBackend to "openssl" or "schannel", Git for Windows can now choose the SSL backend at runtime.

This comes in handy on Windows because Secure Channel ("schannel") is the native solution, accessing the Windows Credential Store, thereby allowing for enterprise-wide management of certificates. For historical reasons, Git for Windows needs to support OpenSSL still, as it has previously been the only supported SSL backend in Git for Windows for almost a decade.

The patch has been carried in Git for Windows for over a year, and is considered mature.

Signed-off-by Johannes Schindelin <[email protected]>

---
 Documentation/config.txt |  5 +++++
 http.c                   | 35 +++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+)

Documentation/config.txt +5 -0

index 154683321..7d38f0bf1 100644
@@ -1984,6 +1984,11 @@ http.sslCAPath::
 	with when fetching or pushing over HTTPS. Can be overridden
 	by the `GIT_SSL_CAPATH` environment variable.
 
+http.sslBackend::
+	Name of the SSL backend to use (e.g. "openssl" or "schannel").
+	This option is ignored if cURL lacks support for choosing the SSL
+	backend at runtime.
+
 http.pinnedpubkey::
 	Public key of the https service. It may either be the filename of
 	a PEM or DER encoded public key file or a string starting with

http.c +33 -0

index 98ff12258..7fb37a061 100644
@@ -155,6 +155,8 @@ static struct active_request_slot *active_queue_head;
 
 static char *cached_accept_language;
 
+static char *http_ssl_backend;
+
 size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
 {
 	size_t size = eltsize * nmemb;

@@ -302,6 +304,12 @@ static int http_options(const char *var, const char *value, void *cb)
 		curl_ssl_try = git_config_bool(var, value);
 		return 0;
 	}
+	if (!strcmp("http.sslbackend", var)) {
+		free(http_ssl_backend);
+		http_ssl_backend = xstrdup_or_null(value);
+		return 0;
+	}
+
 	if (!strcmp("http.minsessions", var)) {
 		min_curl_sessions = git_config_int(var, value);
 #ifndef USE_CURL_MULTI

@@ -995,6 +1003,33 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
 	git_config(urlmatch_config_entry, &config);
 	free(normalized_url);
 
+#if LIBCURL_VERSION_NUM >= 0x073800
+	if (http_ssl_backend) {
+		const curl_ssl_backend **backends;
+		struct strbuf buf = STRBUF_INIT;
+		int i;
+
+		switch (curl_global_sslset(-1, http_ssl_backend, &backends)) {
+		case CURLSSLSET_UNKNOWN_BACKEND:
+			strbuf_addf(&buf, _("Unsupported SSL backend '%s'. "
+					    "Supported SSL backends:"),
+					    http_ssl_backend);
+			for (i = 0; backends[i]; i++)
+				strbuf_addf(&buf, "\n\t%s", backends[i]->name);
+			die("%s", buf.buf);
+		case CURLSSLSET_NO_BACKENDS:
+			die(_("Could not set SSL backend to '%s': "
+			      "cURL was built without SSL backends"),
+			    http_ssl_backend);
+		case CURLSSLSET_TOO_LATE:
+			die(_("Could not set SSL backend to '%s': already set"),
+			    http_ssl_backend);
+		case CURLSSLSET_OK:
+			break; /* Okay! */
+		}
+	}

Quoted 8 lines

http.c void http_init(struct remote *remote, const char *url, int proactive_auth) · line 1034

Quoted 4 lines

http.c +2 -0

+#endif
+
 	if (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)
 		die("curl_global_init failed");

Here's someone who upgraded to 2.20 on Arch linux & started getting "Could not set..." errors because of this change:
https://www.reddit.com/r/git/comments/a5ne5v/git_fatal_could_not_set_ssl_backend_to_openssl/

Yeah, I don't see bug reports that were opened via Reddit.

Quoted 3 lines

I don't know the context well enough, but is there perhaps enough info here so we could give a better error message, e.g. "don't set xyz twice in your config", or just emit a warning?

This is actually not the symptom of a Git bug, but of a cURL bug that I fixed in https://github.com/curl/curl/pull/3346. I suspect the fix for this particular symptom to be
https://github.com/curl/curl/commit/231a328c1c563acb53d8222894975e96bf7e6ea7

(Granted, I introduced that bug, and did not catch it earlier because I almost never build cURL with a single TLS backend these days, and that is necessary to trigger the bug.)

According to https://curl.haxx.se/changes.html, this bug fix
(https://curl.haxx.se/bug/?i=3346) made it into v7.63.0, which is one day old.

Feel free to update that Reddit post (I don't have an account, nor any inclination to get one).

Ciao,
Dscho