Matching a name to a port
Jacques A. Vidrine
nectar at FreeBSD.org
Mon Sep 13 11:36:48 PDT 2004
On Mon, Sep 13, 2004 at 02:16:37PM -0400, Dan Langille wrote:
> On Mon, 13 Sep 2004, Jacques A. Vidrine wrote:
>
> > On Mon, Sep 13, 2004 at 01:33:22PM -0400, Dan Langille wrote:
> > > I'm trying to match vuln.xml information against actual ports. To do
> > > this, I need to know how the entries in the <name> field are derived.
> > >
> > > I first thought it might be PORTNAME. But that's not the case. I now
> > > think it might be ${PKGNAMEPREFIX}${PORTNAME}$.
> >
> > ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}
> >
> > See the definition of PKGNAME in bsd.port.mk. It is PKGNAME minus the
> > version information.
> >
> > > If am i correct, then I have some questions about the following entries.
> > >
> > > What ports do the following refer to?
>
> Jacques: Thanks for pointing out the ports I missed. I have snipped them
> from the discussion so we can concentrate on the others.
>
> > > ImageMagick-nox11
> > graphics/ImageMagick
>
> I see ImageMagick in the names for this vuln. Where does
> ImageMagick-nox11 enter the picture?
Good point. ImageMagick-nox11 is probably also affected, and
probably should also be listed. (I'll correct.) If one installs
graphics/ImageMagick with the WITHOUT_X11 variable defined, then you
get ImageMagick-nox11.
> > > libtool
> > depends, could be devel/libtool13 or devel/libtool15, or even the
> > no-longer-existent devel/libtool or devel/libtool14
>
> Looking at the data:
>
> <package>
> <name>libtool</name>
> <range><ge>1.3</ge><lt>1.3.5_2</lt></range>
> <range><ge>1.4</ge><lt>1.4.3_3</lt></range>
> <range><ge>1.5</ge><lt>1.5.2</lt></range>
> </package>
>
> I suggest we need three package entries to cover the various FreeBSD ports
> which have existed. Please see the mysql suggestion below for an example
> of what I mean.
It would not work, see below.
> This URL shows the libtool ports in question.
>
> http://www.freshports.org/search.php?stype=name&method=match&query=libtool&num=10&deleted=includedeleted&casesensitivity=caseinsensitive&search=Search&orderby=category&orderbyupdown=asc
>
>
> > > mpg123-esound
>
> We have mpg123, but no mpg123-esound. I wonder where it comes from.
If you build mpg123 with Gnome, you get mpg123-esound.
> > > mplayer-esound
> > > mplayer-gtk
> > > mplayer-gtk-esound
> >
> > multimedia/mplayer
>
> I don't know what to do about those. The vuln has an entry for mplayer,
> so we'll catch that on FreshPorts, but not the other tree.
Which <vuln> is it? It seems that the <vuln>s in
ports/security/vuxml/vuln.xml related to mplayer each list all of these
package names.
> > > mysql-client
> > > mysql-scripts
> > > mysql-server
> > depends, could be any of the database/mysql*-(client|scripts|server) ports.
>
> FreshPorts, or any other code for that matter, has no way
> of knowing that port this vuln entry refers to.
That's because there is no such thing as an affected "port", only an
affected "package".
> Intuitively, yes, we know it's going to be one of mysql323-client,
> ysql40-client, and mysql50-client.
>
> Yes, the range entries help human eyes:
>
> <range><ge>4.1</ge><lt>4.1.3</lt></range>
> <range><ge>5</ge><le>5.0.0_2</le></range>
It is also used by any code that checks for vulnerable packages, such
as portaudit or vxquery.
> I suggest we need two packages:
>
> <package>
> <name>mysql40-client</name>
> <range><ge>4.0</ge><lt>4.0.20</lt></range>
> <range><ge>4.1</ge><lt>4.1.1_2</lt></range>
> </package>
> <package>
> <name>mysql50-client</name>
> <range><ge>5.0</ge><lt>5.0.0_2</lt></range>
> </package>
> </affects>
No, this would be wrong and would not match any packages ever
installed by the FreeBSD Ports Collection. e.g. There is a package
``mysql-client-4.0.18_1'', but never has there been a package
``mysql40-client-4.0.18_1'' and there will never be.
> Should the entry be modified to refer explicity to
Something truncated here?
> > > The answers may be obvious to the trained eye, but how does one write code
> > > against this?
> >
> > Ports are re-named, moved, removed. I'm not sure that it can be
> > done exactly other than by what I suggested previously: a database
> > of the "history" of package names. IIRC, portupgrade uses ad hoc
> > heuristics to guess the port origin from the package name, when the
> > ORIGIN comment is not usable for some reason.
> >
> > The dichotomy of package name and port origin has always been a
> > troublesome aspect of the FreeBSD Ports collection :-(
>
> Moving things around isn't so much of a problem. Locating them in the
> first place is the issue. Later moves are not a problem.
I'm not sure what you mean :-( Maybe you mean once you have the package
names correlated to port names within FreshPorts, later moves will be
"caught" automatically?
Cheers,
--
Jacques Vidrine / nectar at celabo.org / jvidrine at verio.net / nectar at freebsd.org
More information about the freebsd-vuxml
mailing list