-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
Comments
I cannot spot this in source code. It was renamed from Line 2742 in 7e814c8
It is unfortunate that the |
Has something changed in the code that normalizes the value for the |
Aha! There was 810933d which placed Secure-Transport after OpenSSL. A name in 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 |
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. |
I still think it would be better that in case of an unrecognized/unsupported It is quite weird that if the default backend is openssl, and you set |
- 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
|
- 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
I did this
The default libcurl 8.7.1 configuration on MacOS has two ssl backends. The ssl_version string says
Hence the default is LibreSSL. For a long time I have had the following environment variable on my system:
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?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 inCURL_SSL_BACKEND
.I expected the following
No response
curl/libcurl version
curl 8.11.1
operating system
MacOS
The text was updated successfully, but these errors were encountered: