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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]