CURL_SSL_BACKEND value for SecureTransport has changed?

[jeroen]

I did this

The default libcurl 8.7.1 configuration on MacOS has two ssl backends. The ssl_version string says

(SecureTransport) LibreSSL/3.3.6

Hence the default is LibreSSL. For a long time I have had the following environment variable on my system:

CURL_SSL_BACKEND=SecureTransport

So thereby libcurl would switch to SecureTransport. However I noticed this stopped working for my latest curl build 8.11.1. After reading the Environment variables libcurl understands docs, I found out that the value now requires a hyphen?

CURL_SSL_BACKEND=Secure-Transport

Is this change intended? It caught me by surprise because the ssl version in curl --version does not use the hyphen so it is quite confusing that this does not mach the value that we need to set in CURL_SSL_BACKEND.

I expected the following

No response

curl/libcurl version

curl 8.11.1

operating system

MacOS

[bagder]

I cannot spot this in source code. It was renamed from darwinssl to secure-transport in 76a9c3c and seems to have been untouched in source code since:

curl/lib/vtls/sectransp.c

Line 2742 in 7e814c8

{ CURLSSLBACKEND_SECURETRANSPORT, "secure-transport" }, /* info */

It is unfortunate that the curl -V output shows it differently, but I don't think we can change that now.

[jeroen]

Has something changed in the code that normalizes the value for the CURL_SSL_BACKEND environment variable? I suppose it also has to get lowercased somewhere because it is case insensitive?

[icing]

Has something changed in the code that normalizes the value for the CURL_SSL_BACKEND environment variable? I suppose it also has to get lowercased somewhere because it is case insensitive?

Aha! There was 810933d which placed Secure-Transport after OpenSSL. A name in CURL_SSL_BACKEND that is not recognised falls back to the first SSL backend available.

So, it seems you always had the "wrong" name, but it did what you wanted.

[jeroen]

So, it seems you always had the "wrong" name, but it did what you wanted.

Great, great, haha. Good to know.

Maybe we could normalize the value of CURL_SSL_BACKEND and strip non alphanumeric characters before processing it? And if it is unrecognized: fall back on the default openssl backend, instead of what comes first in that list?

[bagder]

Maybe we could normalize the value

Hm, yeah perhaps but a little overkill maybe? The valid names are documented and I don't really believe in "lenient" checks to try to guess what the user really wanted.

[jeroen]

I still think it would be better that in case of an unrecognized/unsupported CURL_SSL_BACKEND value, curl uses the ssl backend that is configured as the default, instead whatever comes first in that list.

It is quite weird that if the default backend is openssl, and you set CURL_SSL_BACKEND=yolo, the ssl backend becomes SecureTransport.

[jay]

It is quite weird that if the default backend is openssl, and you set CURL_SSL_BACKEND=yolo, the ssl backend becomes SecureTransport.

#16108