Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Aug 2004 14:40:25 -0500
From:      "Jacques A. Vidrine" <nectar@FreeBSD.org>
To:        Oliver Eikemeier <eikemeier@fillmore-labs.com>
Cc:        Pete Fritchman <petef@absolutbsd.org>
Subject:   Re: cvs commit: ports/security/portaudit-db/database portaudit.txt portaudit.xlist portaudit.xml
Message-ID:  <20040822194025.GB17478@madman.celabo.org>
In-Reply-To: <1F055B5E-F084-11D8-924A-00039312D914@fillmore-labs.com>
References:  <20040817185332.2B91D1800A@sirius.firepipe.net> <1F055B5E-F084-11D8-924A-00039312D914@fillmore-labs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 17, 2004 at 09:32:05PM +0200, Oliver Eikemeier wrote:
> Jacques doens't seem to like this: "Aaaaaahh!".

:-)

> I don't really care
> ident(1) is fine for me, and it seems like this is the only reliable
> indication. OTOH you'll need a couple of references (file, list of
> FreeBSD versions). Doable, so when no other ideas pop up we should do
> this.

I don't think ident information is all that useful, and I *know*
that it is a PITA to maintain.  I instituted the current practice
of including revision numbers in FreeBSD Security Advisories.  I
thought it was a good idea at the time :-) But in fact, it is one
of the most time-consuming parts of producing a FreeBSD SA.  From
the correspondance I've received over the last few years, I'm quite
certain that no one really uses them.  Those who *do* use them are
users who are quite capable of accurately determining the revisions on
their own.  In addition, the revisions are often quite misleading.  Some
examples are:

   * Some revisions just aren't important from the perspective of the
     security fix.  src/UPDATING is an obvious case :-) but there are
     less obvious cases, such as result from a merge.

   * Often the revision numbers are not available in the resulting binary.

   * Patches are most often produced *without* the revision number
     changes, since these changes tend to get in the way of tools such
     as patch(1).  Thus, patched systems have "old" revision numbers.

The only practical way to specify affected versions of the system
is with a patch level as we've done for years. e.g.  4.8-RELEASE-p9
is unaffected, all those before are not.  This is analogous to the
situation with ports... we use the package version number, not the
revision numbers of the Makefile and associated ports skeleton files,
nor the revision numbers of the original source files or anything
silly like that.  We use the administratively maintained package
number with PORTEPOCH, PORTREVISION and such.

re@ and so@ actually had a long (unfortunately incomplete) thread
about this kind of thing.  We'd like to be able to decouple the system
version number from the kernel build, but there are lots of details.  I
guess we should revisit this soon, as this becomes IMHO more important
with the advent of errata branches.  (I expect more patch releases.)

Cheers,
-- 
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040822194025.GB17478>