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

Re: security in testing

On Wed, 14 May 2003, Chris Leishman wrote:
> On Wednesday, May 14, 2003, at 10:02 PM, Matt Zimmerman wrote:
> > There is no shortage of opinions about what "we" should do, but there 
> > is unlikely to be any action until an "I" arises who actually does 
> > the work.
> > This has been discussed over and over with the same result each time 
> > (i.e., no action).
> Well, this is why I was suggesting a simpler process.  Since nobody 
> seems to want to spend the effort organising security updates for 
> testing, but lots of people seem unhappy with the idea that testing 
> contains known security bugs, then the packages in question should be 
> simply removed or replaced automatically.
What about having a dummy package "testing-security", consisting of
nothing but a huge list of versioned conflicts (and perhaps a few hints in
/usr/share/doc/ about how to setup a mixed stable/testing or
testing/unstable apt source list)?

This would force those who have packages with known security issues 
already installed to either downgrade to stable or stable/updates, or 
upgrade to unstable (or remove the testing-security package if they 
don't give a damn about security :p ).  Simply removing the package in 
question from the archive is not enough to tip the users that they have
a hole in their boxes.

As the biggest concern seems to be the fact that maintaining four 
distributions at a moment is too much work, it might be a good idea to 
make it take a single command to mark a package as having a security hole.
The idea is to have a script like:
 testingbug hole 1.2.3-45
runnable by the security team, the package maintainer (or perhaps just any 
random DD), which would mark version 1.2.3-45 of the package 'hole' as bad
and upload testing-security_${v+1}_all.deb directly into the testing 
archive.  This is surely a lot simpler than making a NMU just to add a 
debconf warning.  And, even a list that can be tampered with by any DD
is a lot better than no security at all (we trust DDs -- do every of you 
disassemble all the binary upload to find all backdoors created by the 
evil maintainer?).

> 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.
Stable is 1-2 years old, while unstable is often crawling with badly 
broken packages.  Testing is IMO a good choice for a non-DD who wants to 
use new things, but can't always afford to lose several hours just to work 
around a broken package.

Addressing the "we-vs-I" concerns, I (a non-DD) can offer help and devote 
that half an hour of my time it takes to write a script that checks if 
there is a package named X in testing, checks if the version to be marked 
is already replaced by something better in testing, adds the new package 
to the conflicts database, then creates a .deb ready for inclusion in the 
archive.  I'm sure you can do better, this offer is just in case no one 
else cares.  It's for my own selfish reasons -- I personally run testing 
on all my boxes, and having someone type that 'testingbug whatever 1.2.3' 
when a security vulnerability is discovered would save the time I and 
everyone else who uses testing used to lose checking for security issues.


/-----------------------\ Shh, be vewy, vewy quiet,
| kilobyte@mimuw.edu.pl | I'm hunting wuntime ewwows!
Segmentation fault (core dumped)

Reply to: