On Mon, Feb 24, 2003 at 11:11:43AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: > On Mon, 2003-02-24 at 11:06, Peter Cordes wrote: > > On Mon, Feb 24, 2003 at 10:13:57AM +0100, Adrian 'Dagurashibanipal' von Bidder > > wrote: > > > Now, foo 1.4-1 moves to testing with the security problem still unfixed. > > > Damn. > > > > File a bug on foo 1.4-1 so that can't happen until the bug is closed? > > Having stuff which introduces new known security holes move into testing is > > obviously bad under all circumstances, right? > > Sure. The problem is: who files the bug? Would probably be the testing > security team. But if the versions in testing and unstable diverge, I'm > not sure if the security team is supposed to file a bug just so, or is > obliged to additionally verify the version in unstable? (Of course, the > divergence between testing and unstable now is somewhat special, so this > case might not happen too frequently).
Usually security alerts say what versions are affected, and the people who found the problem usually look at the latest versions available from upstream, as well as commonly used older versions. This leads to two common situations: A security problem affecting foo 1.3 and 1.4 is found, and: testing has foo 1.3-1. unstable has foo 1.4-1. response: whoever uploads the security fix to testing should file a bug on the unstable package version if such a bug hasn't been filed by someone else already. If someone (e.g. the maintainer) is working on a fix for the unstable package, she can close the bug when the fix is done. It's not a big problem to have extra bugs related to the same problem filed, esp. for security stuff, as long as the maintainer gets them all closed once they're all fixed. A security problem affecting foo 1.3 and 1.4 is found, and: testing has foo 1.3-1. unstable has foo 1.3-1. (1.4 isn't packaged yet) It's up to the maintainer to not put 1.4 into unstable without fixing the problems, right? (I'm not a Debian developer, and I've never read all the policy docs and stuff. I'm just stating my humble opinion :) The maintainer should be paying attention to their package, so this is different from preventing insecure packages from being moved automatically from unstable to testing. (OTOH, it doesn't really matter who's fault a problem is; preventing the problem is more important than blaming people. If someone has a good idea for preventing known-insecure versions from replacing secure versions in unstable, lets hear it.) -- #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 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
