Deprioritize SecureTransport on macOS

[MonkeybreadSoftware]

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.

[danielgustafsson]

s/Channel/Transport/ =)

[Neustradamus]

To follow this important PR!

[jay]

To follow this important PR!

To follow a thread click the subscribe button. Please don't post a reply to every thread you want to follow just to get subscribed.

[Neustradamus]

@jay: I know but I do not received emails if I do not publish a comment.

[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.

[jay]

I don't see why we would change the order for everyone just to meet your use requirements. We have --with-default-ssl-backend=openssl for configure which maps to CURL_DEFAULT_SSL_BACKEND. We have -DCURL_DEFAULT_SSL_BACKEND=openssl for cmake which maps to same.

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]

[MonkeybreadSoftware]

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.

[vszakats]

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?