On Thu, May 31, 2007 at 01:58:02AM +0100, Ben Hutchings wrote: > > > > What evidence do you have that serious security bugs "won't get fixed" > > > > in a > > > > stable release because of MIA developers?
> > > Search for "years" in > > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&data=security&archive=no&version=&dist=stable&pend-exc=fixed&pend-exc=done&include=security > > If I search on > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag;data=security;archive=no;dist=stable;pend-exc=fixed;pend-exc=done;include=security;severity=critical,grave,serious > > (since the question was about "serious security bugs"), the only matches are > > listed as "From other Branch", meaning that the versions listed as affected > > in the BTS are not versions present in stable. > <snip> > I'm sorry, I did not use "serious" in the precise sense of the BTS. I > meant that there were bugs that could have serious consequences for some > users, which is true of many bugs with severity = important. But if that's the criterion, I don't see why anything more is needed than to more visibly document to our users what classes of bugs are considered release-critical. Maintainer activity is not going to be strongly correlated with frequency of non-RC security bugs in a package in stable. > Also, this release is relatively new and has had less time to accumulate > bug reports. sarge is in a worse state. Ok, can you provide an example to support this claim that sarge is worse? If I sub 'oldstable' for 'stable' in the URL, I get a much *smaller* number of outstanding RC security bugs for sarge, and only two of them are open for longer than a year[1] (and less than two), which is of course not good, but also not what you appeared to be claiming above. I'm not saying that what the BTS shows in this view is at all accurate; I think it's entirely possible that there are bugs missing here, since sarge's release predates the advent of version tracking in the BTS, and even now there's a good chance of new security bugs being filed with incomplete v-t info. I'm just asking that you support this claim with a concrete pointer, because if there are known security bugs going unaddressed I'd like to know what they are to try to understand why they've fallen through the cracks and try to figure out if there's something we can be doing better to catch such bugs as a class. Roberto's point that low maintainer activity tends to correlate with *unknown* security bugs is well taken, but you seem to be making the much stronger claim that we *know* our stable releases have security holes that will go unfixed, and this isn't something that I know at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [1] and one of these bugs is in libtasn1-0, a version of libtasn that appears to have no reverse-dependencies in the archive (I think because the security fix was ABI-breaking and therefore transitioned the reverse-deps away from it), so the impact on end users is roughly nil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
