[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#687916: unblock: zabbix/1:2.0.2+dfsg-4



Hi Julien,

On Sun, 9 Dec 2012 00:45:28 Julien Cristau wrote:
> On Mon, Oct  1, 2012 at 20:07:07 +0200, Moritz Mühlenhoff wrote:
> > For stable-security backporting security issues wasn't feasible due to
> > a lack of continued upstream support for 1.8.x and invasive/complex
> > changes. This shouldn't happen again. If there's no commitment from
> > upstream to support a long term branch it should rather be removed
> > from testing.
> 
> Dmitry, is there such a commitment for 2.0.x for wheezy's lifetime?
> 

Yes, I believe there is but I'm not sure how to support it with evidence.

First of all I feel that Moritz' statement regarding upstream support for 
1.8.x may be a bit inaccurate. As you can see from

	http://www.zabbix.com/rn2.0.4.php

last released Zabbix 1.8.15 was published on 2012-08-20 so I'm not sure if we 
can already declare "lack of continued upstream support for 1.8.x".

Just today I was looking into old CVEs to close in "stable" as per discussion 
in #683273. I found that whenever CVE was reported to upstream using bug 
tracker they commit corresponding fix into dedicated branch that later got 
merged into "trunk" and "1.8" branches so it's not that difficult to isolate 
the changes. Of course when upstream applied security fix to version 1.8.11 it 
may be not too easy to backport it to 1.8.2 but I suspect this problem is not 
unique to Zabbix.

I have very limited experience with security fixes in Zabbix (and in Debian in 
general) so please don't take my words as granted without feedback from 
Christoph and Moritz who are far more experienced that I am.

However to put this situation to proper context I'd like to mention "mysql-
workbench" package (maintained by yours truly) where upstream doesn't have 
public VCS at all. Backporting fixes is only possible by reverse-engineering  
new tarballs releases by comparing huge changesets and trying to make sense of 
changes. To make matters worse upstream is not updating changelog accurate 
enough so you can imagine the challenges. I believe Zabbix is much better in 
that regards.

We can't be sure how well Zabbix will be supporting 1.8.x in the future. 
Obviously they've switched focus to Zabbix 2.0.x and that makes it better for 
us to upgrade to 2.0. While we can't be sure regarding future support for 1.8 
and backporting fixes was proven to be challenging (according to feedback from 
Christoph and Moritz) I think we're all agree that 1.8 is better to be removed 
from "testing" to minimise the risks and the maintenance burden. (I think at 
the moment security fixes are applied to 2.0 first, so even the delay before 
fix will be applicable to 1.8 is bad enough.)

Personally I hope that unblocking 2.0 may be considered as current version in 
"unstable" was remarkably free of troubles but that's just my inexperienced 
opinion. I think Christoph is quite excited about the idea of maintaining 
Zabbix in backports so the tough decision regarding Zabbix' destiny in Debian 
is with you. :)

Thank you.

Regards,
Dmitry.


Reply to: