[DRE-maint] long-term redmine debian packaging

[Antoine Beaupré]

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