Bill,

I was getting ready to counter propose something like what Dave
suggested.  By specifying the specific versions, we can also handle
the ocassional odd case where one specific version is hosed.

This way, if Version 1.2.1 is OK, but 1.2.2 isn't, and 1.2.3 fixes the
problem, we can handle this as well.  I know it isn't as likely a 
problem as having a hole go back into deep history, but it is a possible
event.

Dave Burgess

David Brownlee wrote:
> 
> On Mon, 11 Sep 2000, Bill Sommerfeld wrote:
> 
> > I'd like there two be two new optional package makefile variables:
> >
> > INSECURE_BEFORE= <package-version>
> >
> >    This declares that packages older than the specified package-version
> >    may contain known security holes and should be upgraded ASAP.
> >
>         I'd prefer to see this as INSECURE_VERSIONS and use the
>         standard dewey compares (eg: '<1.2.4'). This allows us to
>         handle the case where version formats change - 20000809 is
>         insecure, but 1.0.1 is not.
>         I'm more than happy to tweak lintpkgsrc to do things with
>         the value :)
> 
> > RECENT_ADVISORIES= <url>
> >
> >    This is intended to contain one or more URLs containing security
> >    advisories explaining why the INSECURE_BEFORE entry was added.
> >
> > Intended usage:
> >
> >  - Reduce the effort needed to generate netbsd-specific security
> > advisories for third-party packages.
> >
> >  - Include information in the generated README.html
> >
> >  - Can be used to generate a consolidated "advisory checker" list.
> >
> >  - Allow for the creation of tools which download the most recent
> > package advisory list from a *.netbsd.org server, check vs. installed
> > packages on a system, and email the system administrator suggesting
> > that upgrading the packages would be in order.
> 
>         I like the idea.
> 
>                 David/absolute
>                                -- www.netbsd.org: A pmap for every occasion --