Bug 239375 - libssl installed in /lib but depends on libraries in /usr/lib
libssl installed in /lib but depends on libraries in /usr/lib
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
Depends On: 240277
Blocks: F11Target
  Show dependency treegraph
Reported: 2007-05-07 18:24 EDT by Adam Jackson
Modified: 2009-04-21 05:32 EDT (History)
2 users (show)

See Also:
Fixed In Version: openssl-0.9.8j-10.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-21 05:32:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Jackson 2007-05-07 18:24:12 EDT
Description of problem:

% ldd /lib/libssl.so.0.9.8b 
        linux-gate.so.1 =>  (0x00827000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x04428000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00997000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00976000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x04472000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00955000)
        libcrypto.so.6 => /lib/libcrypto.so.6 (0x00110000)
        libdl.so.2 => /lib/libdl.so.2 (0x00bd3000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00bda000)
        libc.so.6 => /lib/libc.so.6 (0x00a53000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00a25000)
        /lib/ld-linux.so.2 (0x80000000)

Version-Release number of selected component (if applicable):

Comment 1 Tomas Mraz 2007-05-08 15:28:47 EDT
The question is - should openssl libs be moved to /usr/lib or Kerberos libs
moved to /lib? Nalin, what do you think?

Moving libz to /lib shouldn't be a problem as it is a really small library.
Comment 2 Nalin Dahyabhai 2007-05-15 12:55:11 EDT
Hmm, I'm not really a fan of moving Kerberos to /, but given that there are
binaries in /sbin and /bin which require OpenSSL, I don't think we can move
OpenSSL's libraries.
Comment 3 Tomas Mraz 2007-05-15 13:20:22 EDT
Perhaps these binaries could require just libcrypto.so and not libssl.so.

On almost full rawhide install:

Binaries depending on libssl.so: /bin/rpm

Binaries depending on libcrypto.so: /bin/rpm /sbin/dhcp6c /sbin/grubby
/sbin/nash /sbin/setkey

I suppose rpm case is due to linkage to libneon which is already in /usr/lib.

Perhaps there should be 2 rpm binaries one without HTTP(S) support in /bin and
one with it in /usr/bin?
Comment 4 Nalin Dahyabhai 2007-05-15 14:07:45 EDT
That's weird: rpm-4.4.2-46.fc7 on x86_64 doesn't have a dependency between
/bin/rpm and either libssl or libcrypto, which suggests to me that there's only
some link-time cleanup needed there.

Attempting to relink "setkey" with "-Wl,-as-needed" added to setkey_LDFLAGS in
the right Makefile.am removed both its libcrypto and Kerberos dependencies, so
that might as easily fall out as well.
Comment 5 Tomas Mraz 2007-05-16 04:12:53 EDT
My rawhide wasn't fully updated. The rpm libneon dependency was apparently
recently dropped.

So I propose to move libssl.so to /usr/lib and leave libcrypto in /lib. Nalin,
do you think it can bring any problems that the openssl package would own some
libraries in /usr/lib and some in /lib? I can think of just a little bit
confusion to users but that shouldn't be a problem.
Comment 6 Nalin Dahyabhai 2007-05-16 10:51:29 EDT
I don't think it'll be a problem once nothing in /bin and /sbin depends on it. 
If we want to be serious about it, we should probably have a look at /lib and
its subdirectories, too.  I know we've got some modules for PAM which depend on
libraries in /usr/lib.
Comment 7 Tomas Mraz 2007-05-16 12:09:49 EDT
PAM is a different case. The /lib(64)/security path to modules is hardcoded into
the PAM library and I don't think it is worth it to add another
/usr/lib(64)/security directory to libpam as a search path. So there will always
be modules in /lib(64)/security which depend on things in /usr. The basic
modules contained in pam package itself don't and I think that's sufficient.

Otherwise I completely agree - there are many other binaries and libraries in
/bin /sbin and /lib linking to /usr/lib.
Comment 8 Bug Zapper 2008-04-03 20:35:25 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 9 Bug Zapper 2008-05-13 22:52:09 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 10 Tomas Mraz 2008-05-16 09:26:15 EDT
Stupid bug zapper! Cannot you see that this bug blocks F10Target??
Comment 11 Bug Zapper 2008-11-25 20:53:44 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 12 Jon Stanley 2008-11-26 14:13:23 EST
Fixing version to align with rawhide again.  Sorry for the noise.
Comment 13 Tomas Mraz 2009-04-21 05:32:39 EDT
Fixed in F11 by moving libraries to /usr/lib{64,}/ as nothing in / depends on openssl anymore.

Note You need to log in before you can comment on or make changes to this bug.