Bug#787712: libcurl: relocation error libcurl.so.4: symbol SSLv3_client_method

[Peter T. Breuer]

Package: libcurl3
Version: 7.42.1-2+b1
Severity: important
File: libcurl

Dear Maintainer,

[red alert - I've recently done a dist upgrade from old-stable to stable]

It looks as though libcurl.so.4 has calls in it to SSLv3_client_method
which it tries to resolve against libssl.so.1.0.0 (which knows nothing
about any SSLv3_* stuff) whereas it probably should be resoving against
libgnutls-openssl.so.27.0.2. My copy certainly contains those strings,
but its symbol table is stripped so I can't say for sure .. however
libgnutls-openssl.a DOES contain the symbol 000007f0 T SSLv3_client_method
so it's pretty well certain that the .so does as well.

This manifests for me only when running cmake

% cmake .
cmake: relocation error: /usr/lib/i386-linux-gnu/libcurl.so.4:
symbol SSLv3_client_method, version OPENSSL_1.0.0 not defined in
file libssl.so.1.0.0 with link time reference

and freetuxtv

% freetuxtv
freetuxtv: relocation error: /usr/lib/i386-linux-gnu/libcurl.so.4:
symbol SSLv3_client_method, version OPENSSL_1.0.0 not defined in
file libssl.so.1.0.0 with link time reference

and presumably other users of curl.so.4.

It was sort-of cured by preloading libgnutls-openssl.so.27.0.2.so for a
while after I tried recompiling the debian-stable source of curl,
adding -lgnutls-openssl to the LIBS list wherever I could, but I
couldn't get ths hared library to point the right way so I've tried
upgrading to the unstable set of curl stuff instead, and now

% setenv LD_PRELOAD /usr/lib/i386-linux-gnu/libgnutls-openssl.so

doesn't help. Yes, libcurl.so.4 is pointing at .so.4.3.0:

% ll /usr/lib/i386-linux-gnu/libcurl.so.4
lrwxrwxrwx 1 root 16 Jun 3 12:32 /usr/lib/i386-linux-gnu/libcurl.so.4 -> libcurl.so.4.3.0
% ll /usr/lib/i386-linux-gnu/libcurl.so.4.3.0
-rw-r--r-- 1 root 538168 Jun 3 12:32 /usr/lib/i386-linux-gnu/libcurl.so.4.3.0

and indeed, it tries to resolve against libssl.so.1.0.0, which can't help
it:

% ldd /usr/lib/i386-linux-gnu/libcurl.so.4 | grep ssl
libssl.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0 (0xb7570000)

So, what's up? Do you know? My experience of debian maintainers is
that typically you don't do debugging, and just wait around in case
somebody solves it by accident or it gets solved in some upstream
upgrade years later, or the package goes away. I don't have any
sympathy ... debugging is what the job entails, and upstream will think
the same. You caused it, you fix it. I'm willing to help you, so press
the email button and I'll apply my C skills and you can apply your
configuration knowhow, and we should be able to figure it out.

How on Earth does libcurl.so.4.3.0 end up pointing at libssl1.0.0? Is
that a weak/strong symbols thing?


*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.7-betty (PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libcurl3:i386 depends on:
ii libc6 2.19-18
ii libcomerr2 1.42.12-1.1
ii libgssapi-krb5-2 1.12.1+dfsg-19
ii libidn11 1.29-1+b2
ii libk5crypto3 1.12.1+dfsg-19
ii libkrb5-3 1.12.1+dfsg-19
ii libldap-2.4-2 2.4.40+dfsg-1
ii librtmp1 2:2.4~20150315.gita107cef9b-dmo1
ii libssh2-1 1.4.3-4.1
ii libssl1.0.0 1.0.2-1
ii zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages libcurl3:i386 recommends:
ii ca-certificates 20141019

libcurl3:i386 suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Alessandro Ghedini]

Control: reassign -1 openssl
Control: forcemerge 768476 -1
Control: affects -1 + libcurl3

On gio, giu 04, 2015 at 11:52:27 +0100, Peter T. Breuer wrote:
> Versions of packages libcurl3:i386 depends on:
> ii libc6 2.19-18
> ii libcomerr2 1.42.12-1.1
> ii libgssapi-krb5-2 1.12.1+dfsg-19
> ii libidn11 1.29-1+b2
> ii libk5crypto3 1.12.1+dfsg-19
> ii libkrb5-3 1.12.1+dfsg-19
> ii libldap-2.4-2 2.4.40+dfsg-1
> ii librtmp1 2:2.4~20150315.gita107cef9b-dmo1
> ii libssh2-1 1.4.3-4.1
> ii libssl1.0.0 1.0.2-1

libssl1.0.0 version 1.0.2-1 only ever existed in experimental and is now
outdated (replaced by 1.0.2a-1 in unstable). Your problem is the same as bug
#768476 [0] which is *not* a libcurl3 bug, and can be solved by updating the
libssl1.0.0 package to version 1.0.2a-1.

Cheers

[0] https://bugs,debian.org/768476