NetBSD Problem Report #35281

From perry@piermont.com  Tue Dec 19 15:26:51 2006
Return-Path: <perry@piermont.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 109BA63BA6D
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 19 Dec 2006 15:26:51 +0000 (UTC)
Message-Id: <20061219152650.3E9F078B608@hackworth.piermont.com>
Date: Tue, 19 Dec 2006 10:26:50 -0500 (EST)
From: perry@piermont.com
Reply-To: perry@piermont.com
To: gnats-bugs@NetBSD.org
Subject: pkg-vulnerabilities can be garbage collected
X-Send-Pr-Version: 3.95

>Number:         35281
>Category:       pkg
>Synopsis:       pkg-vulnerabilities can be garbage collected
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 19 15:30:00 +0000 2006
>Closed-Date:    Mon Jun 06 05:39:38 +0000 2022
>Last-Modified:  Mon Jun 06 05:39:38 +0000 2022
>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:


>Release-Note:

>Audit-Trail:
From: "Jeremy C. Reed" <reed@reedmedia.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/35281: pkg-vulnerabilities can be garbage collected
Date: Tue, 19 Dec 2006 09:59:13 -0600 (CST)

 Maybe add an option to only display the latest two vulnerabilities for 
 each package?

 Keeping all in list makes it convenient for end-user to know if any of the 
 vulnerabilities are of concern and also for pkgsrc developers so they can 
 quickly see if some issues have been resolved or not.

 By the way, the custom audit-packages I use sorts the output with | sort 
 -f so is easier to read.

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 06 Jun 2022 05:39:38 +0000
State-Changed-Why:
(a) The right way to propose a change like this is on tech-pkg. Here,
nobody sees it, as witness how long this PR has sat open.

(b) The list serves a second purpose, which is keeping track of vuls
that still need to be patched. At most, only fixed ones can be folded
together.

(c) While it's annoying that the file grows without bound, it's still
not large enough to be a problem.

Based on points (b) and (c) I don't think this is a great idea, but if
you can convince tech-pkg, go for it...


>Unformatted:

Home	PR Database Search