Date: Thu, 17 Jun 2010 11:08:07 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: questions@freebsd.org Subject: Re: Detecting fake library versions Message-ID: <alpine.BSF.2.00.1006171042400.74410@wonkity.com> In-Reply-To: <4C1A4119.1080402@infracaninophile.co.uk> References: <alpine.BSF.2.00.1006161240460.69965@wonkity.com> <alpine.BSF.2.00.1006161852460.70963@wonkity.com> <4C19D01C.6050303@infracaninophile.co.uk> <alpine.BSF.2.00.1006170640070.73790@wonkity.com> <4C1A4119.1080402@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1006171042400.74410>