>Number:         35281
>Category:       pkg
>Synopsis:       pkg-vulnerabilities can be garbage collected
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 19 15:30:00 +0000 2006
>Originator:     Perry E. Metzger
>Release:        NetBSD 4.99.3
>Organization:
Perry E. Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
>Environment:
	
	
System: NetBSD hackworth 4.99.3 NetBSD 4.99.3 (HACKWORTH) #0: Fri Oct 27 14:05:48 EDT 2006 perry@hackworth:/usr/obj/sys/arch/i386/compile/HACKWORTH i386
Architecture: i386
Machine: i386
>Description:

The "pkg-vulnerabilities" file contains lines that effectively can be
summarized as "don't use versions of a package below version X". When
there are lots of lines with a strict "<" relation, all but the last
one are effectively redundant.

Currently, policy is to keep all lines, vis:

# Note: NEVER remove entries from this file; this should document *all*
# known package vulnerabilities so it is entirely appropriate to have
# multiple entries in this file for a single package.

I would propose that this is not strictly necessary. For any package
with multiple "<" lines, only two really need be kept -- the most
recent one, and the last one before, with the vulnerability listed
changed to some sort of indicator of "multiple vulnerabilities". Why
keep a second line? Just so people are aware that the most recent vuln
is not the only one.

However, there is no reason to have five or eight or fifteen or in
some cases over 30 lines for a given package. No real security purpose
is served by this, and it often ends up clogging the user's email if
they're running the nightly vuln audit so much that they can't really
figure out what's in need of fixing.

Also, the longer the file is, the more of a burden it is on our
machines for large numbers of users to be downloading it nightly, and
right now the file is (by my calculations) something like twice as
large as it needs to be.

>How-To-Repeat:
	
>Fix:
	

>Unformatted: