Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CURL_SSL_BACKEND value for SecureTransport has changed? #16076

Closed
jeroen opened this issue Jan 23, 2025 · 7 comments
Closed

CURL_SSL_BACKEND value for SecureTransport has changed? #16076

jeroen opened this issue Jan 23, 2025 · 7 comments
Labels
libcurl API not-a-curl-bug This is not a bug in curl TLS

Comments

@jeroen
Copy link
Contributor

jeroen commented Jan 23, 2025

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
Copy link
Member

bagder commented Jan 23, 2025

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:

{ 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
Copy link
Contributor Author

jeroen commented Jan 23, 2025

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
Copy link
Contributor

icing commented Jan 23, 2025

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
Copy link
Contributor Author

jeroen commented Jan 23, 2025

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 bagder added the not-a-curl-bug This is not a bug in curl label Jan 23, 2025
@bagder
Copy link
Member

bagder commented Jan 23, 2025

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.

@bagder bagder closed this as completed Jan 24, 2025
@jeroen
Copy link
Contributor Author

jeroen commented Jan 28, 2025

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 added a commit to jay/curl that referenced this issue Jan 28, 2025
- Use build-time CURL_DEFAULT_SSL_BACKEND as a fallback when environment
  variable CURL_SSL_BACKEND contains a backend that is unavailable.

Prior to this change if CURL_SSL_BACKEND was set then
CURL_DEFAULT_SSL_BACKEND was ignored, even if the backend of the former
was unavailable. In that case libcurl would instead select the first
available backend in the list of backends.

Bug: curl#16076 (comment)
Reported-by: Jeroen Ooms

Closes #xxxx
@jay
Copy link
Member

jay commented Jan 28, 2025

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

#16108

jay added a commit that referenced this issue Jan 28, 2025
- Use build-time CURL_DEFAULT_SSL_BACKEND as a fallback when environment
  variable CURL_SSL_BACKEND contains a backend that is unavailable.

Prior to this change if CURL_SSL_BACKEND was set then
CURL_DEFAULT_SSL_BACKEND was ignored even if the backend of the former
was unavailable. In that case libcurl would instead select the first
available backend in the list of backends.

Bug: #16076 (comment)
Reported-by: Jeroen Ooms

Closes #16108
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libcurl API not-a-curl-bug This is not a bug in curl TLS
Development

No branches or pull requests

4 participants