Hi! ["out of date redmine" bug report in CC. this is a followup email to the generic "we're going to LTS redmine!" notification which expands on the situation and hopefully the future of the Redmine packaging]
I am trying to figure out how to maintain Redmine in the long term, especially in the older debian releases (squeeze, wheezy and yes, eventually jessie!). I have so far taken the near monastic approach of trying to backport every patch i could get my hand on back into squeeze and wheezy, but it's been a slow and difficult process. Fortunately, a lot of the security issues seem to have been appearing after 1.0, so squeeze is often not vulnerable. In other cases, issues have been fixed in squeeze, but *not* in wheezy, sid or even jessie, which I think is a fairly serious problem. As part of my LTS work, I am trying to prepare uploads to fix most if not all of the open vulnerabilities in Redmine. I have therefore reviewed all open security issues in Redmine, well documented here: https://security-tracker.debian.org/tracker/source-package/redmine Here's the summary of the progress so far: * CVE-2015-8537: wheezy and up, patch available in #807826 * CVE-2015-8477: squeeze and wheezy, patch available in github, needs testing * CVE-2015-8474: squeeze and wheezy, patch to be ported, depends on CVE-2014-1985 * CVE-2015-8473: wheezy and up, patch to be ported * CVE-2015-8346: fixed in squeeze only! patch to be ported * CVE-2014-1985: squeeze and wheezy, patch to be ported * CVE-2012-2054: squeeze only, patch to be ported * CVE-2012-0327: squeeze only, patch impossible to find (!) All the details are in the security tracker, but basically, we need better coordination if we want to get rid of those issues more reliably in the future. What I would recommend, at this point, would be to ship patches for the issues we can backport (which is most of the above), but only as a short term fix. Our strategy clearly is not working if we can't get a recent release in sid / testing *and* a secure stable version in stable/LTS. I will try to do those uploads by the end of the month, or at least send debdiffs in various places. I have already documented a bunch of patches and diffs in the above CVEs. In the long term, I think it may be better to use a strategy similar to MySQL or other more monolithic packages in the future. It has been easier to cherry-pick patches in recent CVEs, but it's still hard work that we can't seem to keep up with. By keeping up with upstream releases (pinned against the proper Rails release of course), our jobs would be much easier. This would mean getting 3.5 or 3.6 into shape for stretch and/or jessie. Is there anything blocking that? By the way, backporting the patches is real detective work if the patch is not clearly identified in the CVE. Tracking that through the loops of SVN mystery is absolutely terrible. I made a home-grown script to untangle all this stuff because I couldn't figure out the SVN repository (either it's been too long or what i want i not possible, i am not sure): http://src.anarc.at/scripts.git/blob_plain/HEAD:/redmine-svn-inspector yeah, I know, that's horrible - any improvements would of course be welcome. maybe i just missed something. Thanks for any feedback and happy holidays a. -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir - Lofofora
