Matching a name to a port

Dan Langille dan at langille.org
Mon Sep 13 11:56:19 PDT 2004


On Mon, 13 Sep 2004, Jacques A. Vidrine wrote:

> 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.

FreshPorts knows nothing about ImageMagick-nox11 because there is no such
port.  It knows only about ImageMagick, against which commits are made.

Proposed approach for FreshPorts: I think FreshPorts will ignore package
entries for which it cannot find a corresponding port.  If all packages
for a vuln fail to relate to a port, that will be something which
justifies further investigation.

> > > >  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.

Ahh, I understand now.  Thanks.

> > 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.

Good.  Then the proposal will hold up here.

>
> > > >  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.

I found only one vuln.  5e7f58c3-b3f8-4258-aeb8-795e5e940ff8
And yes, it refers to all the above.

This situation will resolve OK under the proposal.

> > > >  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.

Yep, I've had them in mind too, and was wondering how they did it.  They
have the advantage of a list of installed packages/ports.  FreshPorts does
not.  I now think that's OK.

> > 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.

Of course, yes.  We're back to the basis of package name:

   ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}

FreshPorts has never stored that information. I see now that it will have
to. With luck, this information will be pretty static over the life of a
port and everything will just fall into place with respect to historical
entries.

> > Should the entry be modified to refer explicity to
>
> Something truncated here?

I think I started something, then went and added the above "I suggest we
need two packages:" section and did not remove my uncompleted sentence.

> > > > 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?

Yes. It's hard to phrase.  For example, you can view deleted ports in
FreshPorts, which will retain the history.

-- 
Dan Langille - http://www.langille.org/
BSDCan - The Technical BSD Conference: http://www.bsdcan.org/


More information about the freebsd-vuxml mailing list