Expose SSL/TLS backend that libcurl is built against (in curl-config) #2128

p opened this Issue Nov 30, 2017 · 4 comments


None yet
2 participants

p commented Nov 30, 2017

PycURL (http://pycurl.io/), operating in a multi-threaded environment that is Python, must include thread locking callbacks that depend on the SSL/TLS backend that is being used by libcurl.

In order to include the right callbacks PycURL attempts to detect said SSL/TLS backend during build time. This detection used to look at which libraries listed in curl-config --libs; then OpenSSL changed their library names, then these libraries ceased to be shown in curl-config --libs (and they wouldn't be if libcurl is statically linked against them), and so on and so forth. One of the PycURL build options loads libcurl.so and queries it for its SSL backend via ssl_version in version info structure.

By now there is an extensive collection of code in PycURL attempting this SSL/TLS backend detection and it is far from working in all cases. In fact my recommendation to PycURL packagers would be to explicitly specify the backend given their knowledge of how libcurl is built on their system.

I would like libcurl to expose the SSL/TLS backend it is built against in an easy to use fashion. I imagine that exposing it in some fashion in curl-config --features or exposing the version string as given in ssl_version via a new flag to curl-config are viable options from the users' standpoint.

Note: using libcurl does not require curl binary to exist, hence curl --version does not satisfy the request in this issue.

Note 2: some kind of a Windows solution to this issue will probably be good to have too, although the Windows build process for PycURL builds libcurl and all of its dependencies from source every time and therefore knows which SSL backend libcurl uses, and this is unlikely to ever change.

curl/libcurl version

% curl --version
curl 7.56.1 (x86_64-pc-linux-gnu) libcurl/7.56.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) libssh2/1.8.0 nghttp2/1.26.0 librtmp/2.3
Release-Date: 2017-10-23
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL 

operating system

Linux, Windows, Mac

ur pushed a commit to p-push/pycurl that referenced this issue Nov 30, 2017

Redo which configurations are being tested in travis.
Drop everything that uses automatic libcurl SSL backend
detection. The automatic detection does not work all the time
(curl/curl#2128) and now that
there are configurations for all SSL backends using the
default one is less necessary.

Do not test against libcurl that ships with ubuntu, as
it does not appear to support HTTP 2.

Test all SSL backends with 2.7 and 3.6.

Drop Python 3.1.

bagder added a commit that referenced this issue Nov 30, 2017

curl-config: add --ssl-backends
Lists all SSL backends that were enabled at build-time.

Fixes #2128

bagder commented Nov 30, 2017

some kind of a Windows solution to this issue will probably be good to have too

Yes, the windows environment completely lacks a curl-config alternative, but I don't know what we can do about that... Ideas are welcome. Generate and build a binary executable that works the same way?

p commented Nov 30, 2017

Thanks Daniel. I wouldn't worry too much about Windows, just wanted to get it on the radar.


bagder commented Dec 1, 2017

@p so you think the #2129 approach would work for you?

@bagder bagder closed this in 0c65678 Dec 5, 2017


bagder commented Dec 5, 2017


JohnDeHelian pushed a commit to JohnDeHelian/curl that referenced this issue Dec 7, 2017

curl-config: add --ssl-backends
Lists all SSL backends that were enabled at build-time.

Suggested-by: Oleg Pudeyev
Fixes #2128
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment