On Tue, Nov 22, 2005 at 12:41:41AM +0000, Alistair Crooks wrote:
> On Mon, Nov 21, 2005 at 04:21:18PM -0600, erh@swapsimple.com wrote:
> You have missed the point.  People do not know in advance which
> vulnerability they are going to turn up when audit-packages is run -
> it is a vehicle to warn them that an installed package is vulnerable.
> 
> Your changes make it necessary to run audit-packages twice - once to
> encounter the vulnerability, an editing session with /etc/mk.conf
> (which is the wrong place to be mucking around with things like this -
> they would belong in audit-packages.conf if this had been thought
> through), and then another run to spcify your vulnerability id.
> 
> You have sentenced an administrator to do this for every vulnerability
> they encounter.  That is not the way most people run their networks,
> and I believe that you should have considered this before the change
> was made.

	Of _course_ they don't know before hand, but that doesn't mean that 
their set of acceptable vulnerabilties is an all or nothing preference.
So they run the build once, notice "gee, this package that I'm building
has a vulnerability", then decide what to do about it.

The steps you described are _exactly_ the steps I was aiming for.  I think
your idea of the way most people run their networks is a bit off.  Who would
actually want to install a vulnerable pacakge without knowing about it?

Good point about using audit-packages.conf.  Adding a setting in there
wouldn't be too hard to do.  All it'd need is a variable to specify
vulnerability ids in, that would be equivalent to an extra "-i" option.

> It's a good start, but it doesn't go far enough. Support for the deprecated
> value would need to be kept until after the last pkgsrc branch.
> 
> Better still would be to check ALLOW_VULNERABLE_PACKAGES to be a wildcard,
> i.e. if it was set, then SKIP_AUDIT_PACKAGES would automatically be set
> to "yes".

	If it's really that big of a deal to maintain backwards compatibility
here I can go ahead and add it.  I still think using A_V_P is a potential
security risk that should be pointed out.  However, the admin had to have
explicitly set it so, fine, let's keep it as a deprecated value until
the next branch.

> Why do we need vulnerability ids? The URL has always been a fine way of
> identifying vulnerabilities up until now.
	There are 1522 entries in the vulnerabilities file.
	There are only 922 unique urls.

> Why should I allow one vulnerability to pass, and not others? What is
> the point of finer-grained checking?

	Take as an example a recent security vulnerability in the PostgreSQL
database.  It turned out that the vulnerability was that someone with
local access to the database could load arbitrary libraries and execute
code as the user running the database.
	I am perfectly happy installing a package with this vulnerabilities
because no one I don't trust has access to the database in question.
	However, I STILL WANT TO KNOW about e.g. a remote hole in Apache and
I would still want to know about any other vulnerability in PostgreSQL.

I find it rather insane that you would consider the case of 
	"I'm ok installing a package with this one, single vulnerability" 
to be equivalent to
	"I'm ok installing a package no matter what vulnerability it has"

> > > I would just note that pkgsrc is broken for me now as a bulk builder. 
> > > You should either fix things so that old settings are respected, or
> > > revert your changes until such time as backwards-compatible settings
> > > are respected.
> > 
> > Can you tell me what's wrong with setting this:
> > 	SKIP_AUDIT_PACKAGES=yes
> > Just exactly HOW is that broken?
> 
> Because existing configurations no longer work.

	Please explain to me how it worked before.  What I'm hearing is that
bulk builds didn't use the audit check, but there were NO instances
of ALLOW_VULNERABLE_PACKAGES in the bulk pkgsrc files.  None.
Not a single one.  The only other way the audit checks are disabled
are when the pkg-vulnerabilities file doesn't exist, and that still works.

eric