On Tue, Dec 29, 2015 at 04:59:03PM -0500, Antoine Beaupré wrote: > 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. I noticed that soon after this you realized that rails has not been considered as LTS material, and therefore redmine also isn't. if you want to help with the maintainance regardless of that, you are more than welcome. -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: PGP signature