Re: BoF: Supporting 15,000 packages - How much support do we mean?
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.
vorlon@debian.org 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.
Reply to: