[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

conflicts-based solution (was Re: security in testing)



Matt Zimmerman wrote:
> On Wed, May 14, 2003 at 11:53:31PM +0300, Chris Leishman wrote:
> 
> > Then people can bitch and moan about package X not being available and 
> > can do something to fix it (eg. finally start doing security updates 
> > for testing).  Or they can just put up with it.  But either way, their 
> > box wont be a honey pot.
> 
> Removing a package from the archive is not very useful as a security
> measure.  Most users who want the package will already have it installed,
> and it is those users who are most exposed.  It's not unusual for a
> vulnerability to exist for a long time before it is discovered, during which
> time a large number of users will have installed it.

Matt Zimmerman also wrote:
> On Thu, May 15, 2003 at 01:10:18AM +0300, Chris Leishman wrote:
> 
> > So perhaps the replacement is a better way of doing it.  Then the 
> > question is whether you replace it with a dummy empty one, or a 
> > essentially identical working one, except containing a very loud 
> > warning.
> 
> Replacement has its own set of nasty problems, mostly involving
> upgrades to
> and from the original package, and removal/purging of the dummy
> package.

So here's an alternative that would actually work:

Take the harden package, or create something similar: a package that
conflicts with all versions of packages with known security holes. Note
that harden currently does not track all security holes; it has been
released only twice in the past 6 months and the last update for
security conflicts seems to have been in August.

Upload each new release of this package (should be arch: all) to
unstable with urgency=critical. It will enter testing in two days each
time. You might eventually arrange something special with AJ that gets
it into testing with no delay at all, but that's more likely to hapen
once the thing is already in place, and users are already using it, and
we know it actually helps the state of testing and security.

So -- promote the hell out of it. Post to debian-announce, get it added
to the description of testing on the web site, post an article to debian
planet, and to debian-user. Make sure users know about it and install it
when using testing.

Doesn't seem that hard..

-- 
see shy jo

Attachment: pgpXr2JE7NHal.pgp
Description: PGP signature


Reply to: