-
-
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
Deprioritize SecureTransport on macOS #13547
Conversation
Moved SecureChannnel behind OpenSSL, so we can build CURL with both and prefer using OpenSSL over SecureChannel. Our users still can opt-in to use secure channel, but a curl build with both will default to OpenSSL.
s/Channel/Transport/ =) |
To follow this important PR! |
@jay: I know but I do not received emails if I do not publish a comment. |
If the subscribe button is not working for you please contact github support. |
I don't see why we would change the order for everyone just to meet your use requirements. We have For other build systems you'd probably have to pass it as a define to the compiler because there aren't separate options. For example for winbuild with openssl and schannel to use schannel as a default you'd have to pass it like: nmake /f Makefile.vc CC="cl /DCURL_DEFAULT_SSL_BACKEND=\"\"\"\"schannel\"\"\"\"" mode=dll VC=[your vc version number, eg 14] ENABLE_SCHANNEL=yes WITH_SSL=dll SSL_PATH=[your openssl path] |
Thank you. I didn't know these switches and I can add them to my build scripts. The patch here is basically to change the default order in case you don't specify this switch to deprioritize SecureTransport. SecureChannel for Windows is already lower in the list. |
I agree with this, remembering this caused some pain (curl/curl-for-win@fba3391 curl/curl-for-win@55ff9b9) when adding macOS support to curl-for-win. Because on Windows, Schannel didn't take priority, so the macOS behaviour was unexpected. One more reason to deprioritize SecureTransport is that it's deprecated (by Apple) and also without TLS 1.3 support. Likely most users are better served by OpenSSL or its forks than by SecureTransport, and this will only become truer in the future. edit: SecureTransport still has the OS-native certificate bundle support at its advantage IIRC. So perhaps doing this after this has been implemented with OpenSSL/forks, might be the safest road? |
Thanks! |
Moved SecureTransport behind OpenSSL, so we can build CURL with both and prefer using OpenSSL over SecureChannel. Our users still can opt-in to use SecureTransport, but a curl build with both will default to OpenSSL.