Re: openssl upgrade, libcrypto, libssl confusion

From: Anton Shterenlikht <mexas_at_bristol.ac.uk>
Date: Wed, 25 Jul 2012 17:37:27 +0100 (BST)
	On Wed, Jul 25, 2012 at 5:06 AM, Anton Shterenlikht <mexas_at_bristol.ac.uk> wrote:
	> On Wed, Jul 25, 2012 at 12:30:29PM +0100, Anton Shterenlikht wrote:
	>> In /usr/src/UPDATING I see
	>>
	>> 20120712:
	>>         The OpenSSL has been upgraded to 1.0.1c.  Any binaries requiring
	>>         libcrypto.so.6 or libssl.so.6 must be recompiled.  Also, there are
	>>         configuration changes.  Make sure to merge /etc/ssl/openssl.cnf.
	>
	> oops.. wait a minute, I'm still on
	>
	> # uname -a
	> FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012     root_at_mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV  ia64
	> #
	>
	> So this change shouldn't apply to me yet.
	>
	> Still there are *lots* of binaries, and libs
	> linked with /lib/libcrypto.so.6:
	>
	> Binaries that are linked with: /lib/libcrypto.so.6

	...

	> and so on,
	>
	> so is it really right that I can safely delete it?

	    Some ldd/objdump and grep magic will give you the answer you need.
	check-old-libs only points out candidates for removal based on
	existence.
	Cheers,
	-Garrett

That's scary. /usr/src/Makefile calles
these "obsolete", which means these can
be safely deleted:

# check-old-libs      - List obsolete libraries.
# delete-old-libs     - Delete obsolete libraries.

>From what you are saying, and from what
I observe, the algorithm used to determine
whether the libs are obsolete cannot be
trusted.

For example, on another ia64 box, r238540,
I get:

# make -C /usr/src/ check-old-libs
>>> Checking for old libraries
/usr/lib/libftpio.so.8
/lib/libz.so.5
/lib/libutil.so.8
# 

None of these are obsolete.
First, the base OS programs (not ports) depend on these libs:

(I usually use sysutils/libchk to check this)

Binaries that are linked with: /usr/lib/libftpio.so.8
        /usr/sbin/sysinstall

Binaries that are linked with: /lib/libz.so.5
        /usr/sbin/dtrace
        /usr/sbin/lockstat

Binaries that are linked with: /lib/libutil.so.8
        /usr/sbin/sysinstall

Second, at least for libftpio.so.8, there is no
newer version.

Finally, how come I have base OS binaries linked
against old libs, if I always do the orthodox
make buildworld, make buildkernel, make installkernel,
make installworld? This just shouldn't happen, right?

# ls -al /lib/libz.so.*
-r--r--r--  1 root  wheel  151200 Jul 18  2010 /lib/libz.so.5
-r--r--r--  1 root  wheel  155264 Jul 18 11:25 /lib/libz.so.6
# ldd /usr/sbin/dtrace 
/usr/sbin/dtrace:
        libdtrace.so.2 => /lib/libdtrace.so.2 (0x20000000400b2000)
        libproc.so.2 => /usr/lib/libproc.so.2 (0x20000000401b2000)
        libctf.so.2 => /lib/libctf.so.2 (0x20000000401c6000)
        libelf.so.1 => /usr/lib/libelf.so.1 (0x20000000401ee000)
        libz.so.5 => /lib/libz.so.5 (0x200000004022e000)
        libthr.so.3 => /lib/libthr.so.3 (0x2000000040264000)
        libc.so.7 => /lib/libc.so.7 (0x20000000402b2000)
# ls -al /usr/sbin/dtrace 
-r-xr-xr-x  1 root  wheel  58976 Jul 18  2010 /usr/sbin/dtrace

Any why is dtrace so old?

Something is not right here...
Received on Wed Jul 25 2012 - 14:37:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC