Possible to figure out if CURL is using SSL (FreeBSD 13.5-RELEASE-p11 & curl-8.17.0)

Aknot

Aknot

Curl 8.18 seems to have dropped support for OpenSSL versions below 3.x.

Code: 
checking for OpenSSL >= v3... configure: error: OpenSSL 3.0.0 or upper required.

Is there a way to figure out if CURL is using the SSL option on our system, running FreeBSD 13.5-RELEASE-p11?
We have tried the lsof command: lsof -i :443 | grep libcurl but that doesn't give us something.

Our server is running latest latest Magento on Apache with MariaDB among othe things.

Thanks,
 
By default, version 13.x depend on WolfSSL instead of OpenSSL.

ftp/curl/Makefile
OPTIONS_DEFAULT_13= WOLFSSL

Initially, it was modified to depend on gnutls, but as usual, it was a matter of commit, revert, commit.
 
fyi,
Code: 
ldd /usr/local/bin/curl | grep -i ssl
    libssl.so.17 => /usr/local/lib/libssl.so.17 (0x39a21bc54000)
root@myfreebsd:~ # pkg which /usr/local/lib/libssl.so.17
/usr/local/lib/libssl.so.17 was installed by package openssl35-3.5.5
 
Thanks everyone!

I'm an "end user" and not sure what to do here.

We're on the FreeBSD 13.x "built in" OpenSSL, since I was told that installing a newer OpenSSL versions from ports, could cause problems, and I don't like problems.

I tried to switch to gnutls by running make config, but getting this instead:

Code: 
====> You cannot select multiple options from the SSL radio
=====> Only one of these must be defined: GNUTLS OPENSSL
*** Error code 1
...

I'm guessing I'm stuck on curl-8.17.0 😕
 
Aknot said:
We have tried the lsof command: lsof -i :443 | grep libcurl but that doesn't give us something.
Click to expand...
What gave you the idea to run that command? It doesn't make very much sense to me, as curl does not usually listen itself on any port.

We would use curl -V to show the compilation options:
Code: 
π curl -V
curl 8.4.0 (amd64-portbld-freebsd13.2) libcurl/8.4.0 OpenSSL/1.1.1t zlib/1.2.13 libpsl/0.21.2 (+libidn2/2.3.4) libssh2/1.11.0 nghttp2/1.58.0
Release-Date: 2023-10-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets
 
atax1a said:
What gave you the idea to run that command? It doesn't make very much sense to me, as curl does not usually listen itself on any port.
[/code]
Click to expand...
I tried to find a way to see if curl was using the OpenSSL option in my system.
I'm might need to move to FreeBSD 15.x sooner than I hoped for.

Thanks,
 
Alain De Vos said:
I have in make.conf:
DEFAULT_VERSIONS+=ssl=openssl35
Click to expand...
This is probably one of your better, if not the best, solution. However, this will affect other port builds.

Given that FreeBSD 13 retires at the next month upgrading to FreeBSD 14 or 15 would be a better, and in the long run, a more secure option. I have a number of customers/clients still running old unsupported Linux. I've heard all the "reasons" to run old unsupported software. Not a good idea. It's time to upgrade.
 
Aknot said:
Thanks everyone!

I'm an "end user" and not sure what to do here.

We're on the FreeBSD 13.x "built in" OpenSSL, since I was told that installing a newer OpenSSL versions from ports, could cause problems, and I don't like problems.

I tried to switch to gnutls by running make config, but getting this instead:

Code: 
====> You cannot select multiple options from the SSL radio
=====> Only one of these must be defined: GNUTLS OPENSSL
*** Error code 1
...

I'm guessing I'm stuck on curl-8.17.0 😕
Click to expand...
You'll potentially be mixing OpenSSL frOm base and ports, if you have ports that incorrectly links with both for some reason (and indirectly from dependencies) you may up end with compilation and/or runtime issues. In theory this shouldn't be an issue but its rarely tested with the full tree to my knowledge. In many cases using a different library be it GnuTLS, Mbed TLS or wolfSSL is usually fine but there may be some differences in functionality of consumers in the final library / binary compared to OpenSSL due to other libraries being less popular and therefore not having the same featureset implemented even if the library/ies may support all required features. Some applications may also only supports a specific library.
Rough estimates using grep shows the following usage by default and/or only supported library in tree:
~1100 base / OpenSSL (probably more)
~130 GnuTLS
~10 Mbed TLS
~< 5 wolfSSL if you count flavours/variants

Charlie_
You also forgot to mention that it's now broken on 13.5 (i386) using default options (WolfSSL)
 
You must log in or register to reply here.
Back
Top