Detecting fake library versions

[Warren Block]

On Thu, 17 Jun 2010, Matthew Seaman wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17/06/2010 16:04:20, Warren Block wrote:
>>> This is not generally true for shlibs installed from ports, mostly due
>>> to the prevalence of linuxisms like ABI version numbers that aren't
>>> simple integers.  Even so, applying a little intelligent scrutiny to the
>>> list of results will help you sort out any spurious linkage.
>>
>> Could you expand on this part?
>>
>> find reports 83 links in /usr/local/lib.  But only the fake libintl.so.8
>> is linked to a port-created library but not recorded as part of the
>> gettext package.
>
> Right.  In /usr/local/lib on one machine I happen to have the following:
>
> % find /usr/local/lib -name '*.so.*' -type l -ls | cut -c 89-
> /usr/local/lib/libicuio.so.38 -> libicuio.so.38.1
> /usr/local/lib/libutempter.so.0 -> libutempter.so.1.1.5
> /usr/local/lib/libicuuc.so.38 -> libicuuc.so.38.1
> /usr/local/lib/libicule.so.38 -> libicule.so.38.1
> /usr/local/lib/libXaw.so.7 -> libXaw7.so.7
> /usr/local/lib/libdb-4.8.so.0 -> db48/libdb-4.8.so.0
> /usr/local/lib/libdb_cxx-4.8.so.0 -> db48/libdb_cxx-4.8.so.0
> /usr/local/lib/libgs.so.8 -> libgs.so.8.71
> /usr/local/lib/libXau.so.0 -> /usr/local/lib/libXau.so.6
> /usr/local/lib/libicutu.so.38 -> libicutu.so.38.1
> /usr/local/lib/libXaw.so.6 -> libXaw6.so.6
> /usr/local/lib/libiculx.so.38 -> libiculx.so.38.1
> /usr/local/lib/libicui18n.so.38 -> libicui18n.so.38.1
> /usr/local/lib/liblua-5.1.so.1 -> lua51/liblua-5.1.so.1
> /usr/local/lib/libicudata.so.38 -> libicudata.so.38.1
>
> You can see several different patterns here.
>
> Primus: like libdb-4.8.so.0 or liblua-5.1.so.1 --- the shlib is
> installed into a sub-dir of /usr/local/lib and linked back into the main
> directory.  This is generally used when there are several different
> versions of the particular library available in ports.
>
> Secondus: like libXaw.so.6, libXaw.so.7 -- for some reason, the file is
> installed with the ABI version as part of the basename of the file and
> the link just provides the expected name.
>
> Tertius: like libicuio.so.38 and pretty much all the rest.  *BSD uses
> .38 as the ABI version number, whereas linux seems to prefer .38.1 --
> occasionally this sort of thing is the result of developers being
> unclear on the concept of an ABI version number, and just using their
> main code version number.
>
> These are all perfectly normal and as installed from ports -- a little
> work with 'pkg_which' and 'pkg_info -g' will demonstrate that.

That is essentially what the original Ruby script did, slowly, but 
quicker than doing it by hand.

> On the other hand, if I'd seen:
>
> /usr/local/lib/libintl.so.8 -> libintl.so.9
>
> where there is a shlib with the standard ABI version pattern as expected
> under *BSD, but it's a link to another shlib with a *different* major
> version number, then it's pretty clear someone has been bodging things.
>
> Clear enough?

For an interactive method, yes.  I'm trying to find something for the 
people who thought it was a link-and-forget solution instead of a 
temporary workaround.

I just took the approach that a port library with a link that isn't 
part of the port is suspicious.

A much faster yet questionable Ruby version is here:

http://www.wonkity.com/~wblock/fakelib/fastfakelib

-Warren Block * Rapid City, South Dakota USA