On Mon, Jan 14, 2002 at 12:17:15PM -0700, John Galt wrote: > > Okay, this has gone far enough. The reason that s.d.o only deals with > stable is that stable is the only part of Debian that by it's nature > cannot change. For unstable (and now testing) if there's a security bug, > any DD can put up a NMU if it's severe enough, or the regular maintainer > can fix it in a [relatively] short amount of time. It's just not feasable > to expect a change to propagate in stable, because stable doesn't change > at all, except in very small spurts: there have been 5 revisions to > potato in the last [going on 2] years. THIS is the reason that there's no > s.d.o support for testing and unstable. So when woody becomes stable, > there WILL be s.d.o support for woody, because woody won't change. Unitl > they become [stagnant,stable], there is just not enough reason to have > s.d.o support for a distribution.
I think this was well known already, but now that we're sure everyone knows this, I think Micah's idea is interesting. When things are a long way from a freeze/release, you're right, John, it's ok to let security be handled in the current haphazard way it does now. However, how is the testing release (currently woody) going to get any testing if nobody uses it because it's security isn't good enough? Some say you should never run unstable or testing on a machine connected to the internet, but almost all computers are connected to the Internet, at least as clients. This especially applies to the home computers of the average hacker, which is the kind of person who would usefully test and provide feedback on woody. A home system is somewhere I would use a system that wasn't guaranteed to be secure, and where I might have to shut down daemons if no security fix was available for a problem that affected them. (of course I want my machine to be secure, but I can live without guarantees and check on things myself.) I actually use woody on my home NAT firewall, which also runs exim and sshd. (These are the only daemons allowing connections from the outside world on this machine.) Hmm, if a security problem which affects unstable and/or testing, but not stable, is found, what happens? I presume it would get mentioned here, but is a DSA sent out when it's fixed? Would I have to read Bugtraq or something to get notification as soon as it's found (so I could shut down an insecure daemon until the problem was fixed.) I'd rather temporarily give up the ability to ssh into my home machine and check my email than leave it open to attack. > On Mon, 14 Jan 2002, Micah Anderson wrote: > >As woody draws closer and closer to being stable, and potato draws > >closer and closer to the legendary dinosaurs which roamed the earth > >with regards to its outdated software, perhaps this comittment to > >woody's security could be revisted. I would be surprised if a lot of > >the criticsm that is coming out on this issue is not related to the > >fact that a lot of people have moved from potato to woody because they > >cannot continue to use potato due to the requirements of certain > >software or underlying libraries, and are thus burned by this security > >policy. > > > > [...] > > > >Now that woody draws near to being stable, perhaps the policy can be > >altered to accomodate for that. I agree. To get testing better tested (by providing the service more people need to run it), and to get the security team familiar with the soon-to-be-stable release, there could be a mechanism for security fixes to get done on woody, etc. I don't know what kind of security promises would be appropriate, or what, but I think it would be a good idea to do something along these lines. Maybe someone should make a list of packages that the security team would take time to deal with in woody, and add packages to it over time. Starting with popular packages and/or packages classified as required/important might make sense. Here's another idea: Only worry about remote exploits for non-stable dists. Many of the security advisories apply to local security only, and don't let a remote attacker get into the machine in the first place. (Many of them would help an attacker get root after getting a shell running as e.g. nobody or http). Only worrying about remote exploits in soon-to-be-released dists would let a lot more people run them "safely", since a lot of home systems are single user, or at least the other users are trusted/not skilled. (Think family members and roommates. If they crack your system, you can put glue on their doorknob or a snowball in their boots :) For important servers where you really care, like in a business environment, you would certainly want to stick with stable, so no new holes will be introduced, nothing breaks, etc. For systems where you are prepared to live with a little danger, you can run testing and give stuff a workout. When there are known local exploits that haven't been fixed in the dist you're running, it's like running your daemons as root. That isn't the case most of the time, only between when a hole a local priviledge escalation hole is found and when it's fixed. The more I think about it, the more I like my idea. :) Even if we don't worry about testing all the time, it should get some attention as a release approaches. Thanks to the security team for all the work you already do. It's much appreciated. I'm not complaining here, just suggesting ideas. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE