Re: Bug#402829: mantis: not supportable by the security team
Thijs Kinkhorst wrote:
> On Wed, 2006-12-13 at 09:49 +0100, "schönfeld / in-medias-res.com"
> wrote:
> > I quiet understand the etch release policy and I am sure that there are
> > cases where 5a matches the case. But in the case of mantis it does *not*
> > match. Because there is currently *one* open security issue which where
> > just reported and which I'm willing to fix in duration of this day. The
> > package *has* a maintainer and it is not out of date or is *too buggy*.
>
> I think I can say something about this issue. I've been the one actually
> providing the mantis security updates in the sarge lifetime of the
> package.
>
> I've observed the following:
> - There were many, many security problems with mantis in the sarge
> release cyle;
> - Upstream did not provide significant details of vulnerabilities, or
> patches. Also they did not respond to repeated requests from me for
> that information.
>
> > It makes me somehow angry that i invested so much work in bringing
> > mantis back in a good shape, when people can block its release by just
> > saying 'hey it had a bad history'.
>
> You did not add here that the first result of this work only entered
> Debian a couple of weeks ago. While I do value the fact that you've been
> fixing up the package, the few weeks do not give much time to get a
> reliable indication of whether the package has made a radical change.
>
> > Given the information by Moritz that
> > it had 21 vulnerabilities it should be worth to mention that almost 50%
> > of the bugs I've seen affected almost dusty versions of mantis that are
> > *far* away from the current release.
>
> I'm sorry, but I do not buy this. I've fixed a large number of bugs in
> the sarge version of Mantis. The sarge version is 1.5 years old. That
> can hardly be called "far away" or "dusty", can it?
>
> This is about the same lifetime as expected for etch, so if mantis gets
> obsolete that fast, we're better off not packaging it.
>
> > Also most of the bugs has been fixed upstream in a reasonable time
> > and i can *not* confirm that mantis developers do hide details of
> > bug fixes.
>
> I *can*, having worked on actual sarge security updates.
>
> > In fact they use their own bug tracker to track fixes for bugs and
> > the most of the security issues are IMO documented and discussed
> > there well enough to backport/implement security fixes into current
> > debian packages.
>
> They keep bugs closed and requests to open up or to get more
> information, even after an updated version has been released, are met
> with absolute silence.
>
> Maybe this attitude has changed radically in the past couple of months.
> Do you have concrete evidence that they did in fact change their policy
> of handling security issues? And that the code base structurally
> improved the last 1.5 years?
>
> Please provide it then. I do not think it's convincing to use arguments
> like "it was just dusty" to support your point. Debian had the most
> recent version of mantis when sarge released. This didn't seem to be
> quite immune from vulnerabilities.
>
> > Lastly i wanted to note that IMO using statistical numbers that are by
> > *no way* representative isn't really a good base for arguing with a poor
> > user base. And given you do trust that this 40 counted users are a
> > representative number: For this 40 counted users mantis might be *very*
> > important. And it might be even more. There might be hundred that do not
> > participate in popcon.
>
> But this goes for any other package aswell - the point is that these
> numbers can be seen in a relative way: there's a lot of packages that
> have way higher numbers. The security team only has a fixed amount of
> time available to support them. If a package has an exceptionally high
> amount of work compared to a relatively low usage number, this can be a
> valid argument.
JFTR, I agree completely with the situation as Thijs has summarised it.
Cheers,
Moritz
Reply to: