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.
1KB
/-----------------------\ Shh, be vewy, vewy quiet,
| kilobyte@mimuw.edu.pl | I'm hunting wuntime ewwows!
\-----------------------/
Segmentation fault (core dumped)
Reply to: