Re: Sarge freeze and security updates
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(peter@llama.nslug. , 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
Reply to: