cvs commit: ports/security/portaudit-db/database portaudit.txt
Jacques A. Vidrine
nectar at FreeBSD.org
Sun Aug 22 12:40:47 PDT 2004
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
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
* 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.)
Jacques Vidrine / nectar at celabo.org / jvidrine at verio.net / nectar at freebsd.org
More information about the freebsd-vuxml