386841 - Crashreporter linked with libssl.so.4, libcrypto.so.4

Status: VERIFIED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[m.]

User-Agent:       Opera/9.20 (X11; Linux i686; U; en)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007070304 Minefield/3.0a7pre

Crashreporter program linked with libssl.so.4 and libcrypto.so.4, which do not exist in Debian.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Crashreporter does not work.

Expected Results:  
Should be linked with libssl.so, libcrypto.so.

ldd ./crashreporter
...
        libssl.so.4 => not found
        libcrypto.so.4 => not found
...

Comment 1

[dolphinling]

Gentoo doesn't have these either.

Simply symlinking them to lib{ssl,crypto}.so.0.9.8 makes breakpad work (AFAICT).

Comment 2

[Robert Kaiser]

Hrm, I'm on openSUSE 10.2 and when crashing I get

/mnt/mozilla/packages/seamonkey-2.0a1pre.2007070808.en-US.linux-i686/seamonkey/crashreporter: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory

instead of the crashreporter - looks like that's happening on a broad range of distros :(

Comment 3

[m.]

(In reply to comment #1)
> Gentoo doesn't have these either.
> 
> Simply symlinking them to lib{ssl,crypto}.so.0.9.8 makes breakpad work
> (AFAICT).
> 

Even when symlinking them to proper libraries, it does not send the report, but the error message does not say why it fails.. but it's probably not related

Comment 4

[Robert Kaiser]

Actually, sending did work fine for me when I did symlink the .so.4 versions to the .so.0.9.8 binaries.

Comment 5

[Benjamin Smedberg]

Ted/Dave, who wants to take this? Linking directly against libssl.so makes me really nervous, but I'm not sure what the other options are.

Is this a problem where RedHat distros and other distros have radically different soversioning for these libs?

Comment 6

[m.]

Shouldn't applications link against static ssl/crypto libraries instead of shared libraries (for security)?

Comment 7

[(not currently active) Ted Mielczarek]

We're just using `curl-config --libs`, which on my CentOS5 install gives:

-L/usr/kerberos/lib -lcurl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lidn -lssl -lcrypto -lz

I don't see libssl.so.4 in /usr/lib, I wonder if this is specific to our current CentOS4 build platform?  Anyone want to test the builds from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/linux-newref/latest-trunk/ ?  Those are built on the new linux refplatform, which uses CentOS 5.  If this isn't a problem there, then this bug is a non-issue, since we'll be switching to that machine for the official builds probably this week.

Comment 8

[Benjamin Smedberg]

bsmedberg $ ldd linux-newref/firefox/crashreporter
...
        libssl.so.5 => /lib/libssl.so.5 (0x00cde000)
        libcrypto.so.5 => /lib/libcrypto.so.5 (0xf7ca4000)

Comment 9

[(not currently active) Ted Mielczarek]

It seems to work ok if we just link with -lcurl instead of the entirety of CURL_LIBS.  I'll have a patch in a bit.

Comment 10

[(not currently active) Ted Mielczarek]

Attachment: Link with -lcurl instead of CURL_LIBS

This WFM, as libcurl pulls in those other libs anyway.

Comment 11

[Benjamin Smedberg]

Comment on attachment 271541 [details] [diff] [review]
Link with -lcurl instead of CURL_LIBS

We should remove the MOZ_LIBCURL_LIBS configure check and do a AC_TRY_LINK using -lcurl.

Comment 12

[David A. Cobb]

Running UBUNTU 7.04, normal is libssl.0.9.8
Firefox nightlies since about 7/06
Same error, except called lib is "libssl.so.6"

Somehow, we need the install to check for what is available -- or, of course, to link to a non-shared copy which we supply.

Comment 13

[(not currently active) Ted Mielczarek]

The approach used in my patch (with the changes bsmedberg requested in comment 11) are the proper fix for this.

Comment 14

[(not currently active) Ted Mielczarek]

Attachment: AC_TRY_LINK -lcurl in configure

Ok, this adds an AC_TRY_LINK -lcurl (inside of an AC_CACHE_CHECK) to configure.in, and then links to -lcurl in the client Makefile (as before).

Comment 15

[(not currently active) Ted Mielczarek]

Checked in.

Comment 16

[(not currently active) Ted Mielczarek]

This doesn't seem to have fixed it.  I was pretty sure in my testing that it worked, I'm not sure if I missed something, or it never actually worked.

Comment 17

[(not currently active) Ted Mielczarek]

Oh, I think I'm wrong.  I ran `ldd crashreporter` on the CentOS5 system I built it on, and it lists libssl.so.6 etc.  But if I copy it to a different system and run ldd on it, it lists the correct libssl.  Please comment if there are any further issues.

Comment 18

[[:Aleksej]]

Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007071904 Minefield/3.0a7pre on Debian Etch and Sarge.

Comment 19

[dolphinling]

No, it's not fixed. Running ldd crashreporter I get

libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7429000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb72fd000)

but when I actually crash I get 

firefox/crashreporter: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory

Comment 20

[m.]

Works fine here now (Debian unstable).
I tested it by running crashreporter by hand and also by sending ABRT to firefox..
However the crash report is still not sent, for some unknown reason.

Comment 21

[dolphinling]

Oh, whoops. Apparently I was a day behind on updates and didn't notice. Works fine here, sorry.

Comment 22

[Elmar Ludwig]

verified fixed in 2007082304 3.0a8pre nightly build