On Wed, 2007-05-30 at 18:22 -0700, Steve Langasek wrote: > 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. I expect there is some correlation between maintainer activity and competence, and the speed at which security bugs get fixed. That said, the numbers are small and the correlation probably quite weak. So I don't propose to use some sort of karma system to rate maintainers and their packages. > > 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 would expect serious security bugs to be fixed in a *lot* less than a year! There are 6 of them older than 3 months. I fear we'll see the same in etch once it's been out longer. > 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. Let me go through those 6: #382607 (CVE-2006-4041) has apparently not been touched in 9 months. This is probably mitigated by the fix for #368645 (CVE-2006-2314), but this was never confirmed. #392016 should have been closed by version 2.5.7+r1558-4+sarge3, if I'm not mistaken. #396360 (CVE-2006-4513) has been waiting 3 months for someone to apply a patch. #334054 (CVE-2005-3323) has been waiting 19 months for someone to apply a patch (the bug was fixed in zope2.7 but not zope 2.6). #352188 is, as you said, mitigated by the library not having reverse dependencies. And it's a DoS, so is probably only "important". #408300 (CVE-2007-0461) is also a DoS. So at least 2 have apparently fallen through the cracks. There may be more in the security-tracker that aren't in the BTS. > 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. We know that they *will* have security holes found in them. Some of these evidently go unfixed for some time. Maybe this is merely a matter of poor tracking. I think there's a real resource limitation. > [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. Noted. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates
Attachment:
signature.asc
Description: This is a digitally signed message part