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. > I would like to further discuss this topic and hopely we could find a > con sense. Sure, I really hope we can get the mantis package in a good shape. I'm also all for giving a second chance to previously leaky software to change their habits. But that *does* require concrete evidence that something has indeed changed. Especially if you're requesting something like this *very* shortly before the release, with little time to revert any mistakes. It's up to you now: show why mantis deserves the second chance, and why it's essential that it deserves it, at this point, instead of e.g. for Lenny. By the way, I cannot stress too much that I really appreciate your work of getting the sid version in order. I'm just wary to put it in a stable version just a few weeks after. Thijs
Attachment:
signature.asc
Description: This is a digitally signed message part