hurl not linked to system openssl

[chenrui333]

Even though building with OPENSSL_DIR and OPENSSL_NO_VENDOR setup, the hurl still use the bundled openssl rather than the system one, is this the issue with curl-rust?

relates to Homebrew/homebrew-core#134643

[jcamiel]

Hi @chenrui333 ,

I'm not at all versed in OpenSSL stuff, but, in my comprehension, curl-rust use Secure Transport on macOS.
The crate exposes a ssl feature, that is activated by default and that uses the system SSL/TLS library.

Enable SSL/TLS support using the platform-default TLS backend. On Windows this is Schannel, on macOS Secure Transport, and OpenSSL (or equivalent) on all other platforms. Enabled by default.

See https://github.com/alexcrichton/curl-rust/blob/0c1dddf7f1192326614b638a3b7820e4ed9f5b12/Cargo.toml#L43

If we want to build Hurl with curl-rust using OpenSSL, we should, at least, desactivate the ssl feature from curl-rust.

That could be possible if we re-export the ssl feature, like we do for curl/static-ssl, curl-sys/static-ssl:

hurl/packages/hurl/Cargo.toml

Lines 16 to 17 in 2a26671

	[features]
	vendored-openssl = ["curl/static-ssl", "curl-sys/static-ssl"]

People who want to activate the static-ssl should build Hurl with:

$ cargo build --features=vendored-openssl

(BTW, we should have called it vendored-static-ssl instead of vendored-open-ssl, I'll change that)

More information on "Re-exporting dependency features

If you want to test it on your side, you can disable all curl-rust features, ssl being the only default one :

[dependencies]
curl = { version = "0.4.44", default-features = false}

Besides this, I've a question: do we prefer to use the system Secure Channel or a provided Open SSL one? On macOS, I tend to think that it's better to use the systems libraries, especially regarding SSL ? We already use libcurl and libxml2 from the system:

$ otool -L /opt/homebrew/bin/hurl
/opt/homebrew/bin/hurl:
	/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
	/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2202.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)

I don't see the point of doing different for the SSL library. Can you give us more information about why we would use OpenSSL on macOS?

We've also a FAQ in the documentation if you want to use Homebrew's libcurl instead of system's libcurl

Regards,

jc

[chenrui333]

I don't see the point of doing different for the SSL library. Can you give us more information about why we would use OpenSSL on macOS?

that is just the way how we do the formulae maintenance, trying to build the formulae via system dependencies at best efforts.

[jcamiel]

(I hope I didn't sound rude when asking why we want to do this, I really appreciate your work for maintaining the Homebrew formula).
On macOS, the system dependencies is "Secure Channel", not OpenSSL right? Hurl binary should use "Secure Channel" instead of OpenSSL for the SSL/TLS?
On my side, I will try to compile Hurl and see if I can link with OpenSSL 3 (provided by brew)

[chenrui333]

oh, dont feel bad, purely discussion, we do have some formulae use vendored dependencies, but we just disallow them case by case.