On Wed, Dec 28, 2005 at 02:54:17AM -0800, Steve Langasek wrote:
> 
> > * nessusd 2.2.5-3, the server, is linked against both 0.9.7 and
> > 0.9.8
> 
> Ok, I don't see this either:
> 
> $ ldd /tmp/nessus/usr/sbin/nessusd|grep ssl
>         libssl.so.0.9.8 => not found
> $

Funny, it seems that ldd output varies _if_ you have this:

$ dpkg -l "ness*" "*nasl*" |grep ^ii
ii  libnasl2       2.2.5-2        Nessus Attack Scripting Language, shared
lib
ii  nessus         2.2.5-2        Remote network security auditor, the client
ii  nessus-plugins 2.2.5-2        Nessus plugins
ii  nessusd        2.2.5-3        Remote network security auditor, the server
$ ldd /usr/sbin/nessusd |grep ssl
        libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0x40115000)
        libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x403b4000)

However, if you have this:
$ dpkg -l "ness*" "*nasl*" |grep ^ii
ii  libnasl2       2.2.5-3        Nessus Attack Scripting Language, shared
lib
ii  nessus         2.2.5-3        Remote network security auditor, the client
ii  nessus-plugins 2.2.5-2        Nessus plugins
ii  nessusd        2.2.5-3        Remote network security auditor, the server

(libnasl 2.2.5-3 is the version I was preparing which compiles against
libssl.so.0.9.8, it's not in the archive)

Then you get this:
$ ldd /usr/sbin/nessusd |grep ssl
      libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0x40116000)

So, for archs that have compiled libnasl2 against libssl.so.0.9.8 you will
not "see" nessusd linking against both. For archs that have compiled libnasl
aginast libssl.so.0.9.7 you will see that. Tthose archs include i386 at
least, since the packages for i386 were compiled in August by me. Which was
previous to the switch of 0.9.7 to 0.9.8 in libssl-dev (in October).

> Could you please explain why you believe nessusd is linked against both
> versions of the library? 

As said above and easily reproducible. Just install a libnasl2 which has been
compiled aginast 0.9.7.

> To me, this bug looks like it's just an instance
> of #338006.

Indeed, it looks like this might be the end issue. Is it a good idea to force
everyone to use a buggy library? Wouldn't it make sense to provide a
libssl097-dev to prevent breakage for those packages that get bitten by this
bug?

Regards

Javier

Attachment: signature.asc
Description: Digital signature

Reply via email to