Subject: Re: download-vulnerability-list bug?
To: None <itojun@iijlab.net>
From: Alistair Crooks <agc@wasabisystems.com>
List: tech-pkg
Date: 10/21/2002 14:00:25
On Sun, Oct 20, 2002 at 03:17:34PM +0900, itojun@iijlab.net wrote:
> >When trying to update the vulnerability list with download-vulnerability-list
> >just now, I got:
> >New vulnerability list (21149 bytes) is smaller than existing list (21151 bytes)
> >
> >So, I downloaded the new one and diffed it against the one I had:
> >--- vulnerabilities.orig        Sun Oct 20 01:43:04 2002
> >+++ vulnerabilities     Thu Oct 17 09:47:35 2002
> >@@ -1,4 +1,4 @@
> >-# $NetBSD: pkg-vulnerabilities,v 1.197 2002/10/16 23:39:09 itojun Exp $
> >+# $NetBSD: pkg-vulnerabilities,v 1.199 2002/10/17 13:47:08 tron Exp $
> > #
> > # Note: NEVER remove entries from this file; this should document *all*
> > # known package vulnerabilities so it is entirely appropriate to have
> >
> >Perhaps download-vulnerability-list should strip the RCS id out of the files
> >before comparing sizes?
> 
> 	or, comparing the size is not a good idea.  we can't assume that the
> 	file grows constantly (like above, and like correction of URL).

cvs blame will tell you that added the size check :

----------------------------
revision 1.6
date: 2001/04/24 09:32:14;  author: agc;  state: Exp;  lines: +11 -9
Update to version 1.7 of audit-packages.

Incorporates the following changes from Anne Bennett
(anne@alcor.concordia.ca) in PR 12538:

(1) Running download-vulnerability-list as it stands from cron will
    spam the sysadmin with ftp output.  Easy to fix: redirect output
    to /dev/null as per the example in pkg/MESSAGE.  Problem: now
    we lose some error messages as well.  Patch: make sure error
    complaints in that script are spouted to STDERR, not STDOUT.
(3) Minor readability issue: set the source location for the
    vulnerability list in a variable at the top of the script.
(4) PR 12457 reported that audit-packages complained spuriously
    when the vulnerability list had not been updated in over a
    week, and suggested touching it as a solution.  This loses
    the information of when the file was really last updated.
    I'd prefer to always "mv" the new file into place, and use
    mtime instead of ctime in the file freshness test.

I did this part of the PR differently, as I was worried about
incomplete vulnerability lists being downloaded, and overwriting an
existing vulnerability list:

(2) ftp failure in download-vulnerability-list is not being detected
    properly by the current "${FETCH_CMD} .. || (complain; exit 1)"
    test.  Patch: test for a non-zero vulnerability file instead.
    Don't forget to remove any zero-length droppings, if any.

We know that the vulnerability list size will increase, and not
decrease, so test the size of the newly-downloaded file.  If the new
file is smaller than the existing file, then a bad transfer has taken
place - log this fact, and remove the new list.
----------------------------

Please pay attention to the comment at the top of the
pkg-vulnerabilities file - that's why it was put there - and add a
dummy line containing a comment if the size would otherwise decrease.

Thanks,
Alistair