This is my point of view of what to do for this case: My first choice was to not send any unblock request. Reaon is that CVE need privileged account to be exploited, so it is not a high risk, and I would not like to bother anybody.
However, Moritz Muehlenhoff ask me to provide a fix. A fix was already done before the CVE was reported on debian. It is the version 3.5.5. So idea was to send an unblock request to validate this version. That's what Raphael did for me (i received a bounce when doing it myself). This is clearly the choice I recommand for 2 reasons: - On debian, only one CVE was reported, but several others were reported to project directly. Why adding a CVE fix that will include only fixes for the debian CVE and not others ? I think it is better to include others too. - This version and package 3.5.5 is a long term production version. Even if not into debian, it has been released several month ago into tgz package and is really very more stable than current 3.5.4. So if stability of application is a consideration, i think this package is a best choice than a target fix because it fixes other stability bugs (3.5.5 fixes only bugs). I think it is a better choice more secure because the CVE reported into debian is not "one" security report but a long list of several holes (all require privileged account however), so fixing it need a lof of changes on a lof of files. Reporting locally all fixes for only this CVE is a high risk to forget and miss something where we are sure that 3.5.5 is complete and stable. I share point of view of Rapĥael thinking that making a targeted fix does not bring us more security, i will tell more, I think a targetted fix is less secured than 3.5.5 since this version is the official version in production for branch 3.5.5 since begin of october 2014 and no other packages depends on it. 2015-02-09 10:02 GMT+01:00 Raphael Hertzog <hert...@debian.org>: > Hi, > > On Sun, 08 Feb 2015, Ivo De Decker wrote: > > On Wed, Jan 28, 2015 at 09:50:30AM +0100, Raphael Hertzog wrote: > > > Please unblock package dolibarr > > > > > Version 3.5.5+dfsg1-1 fixes a security issue: CVE-2014-7137 (Closes: > #770313) > > > > This bug was filed by the security team as 'grave', but downgraded by the > > maintainer to 'important' without explanation. If the issue is actually > grave, > > the severity should be increased again. > > Well, the maintainer explained (to me only apparently) that the issue is > only exploitable with privileged accounts so that the threat is not very > high and I thus instructed him that it's his reponsibility to downgrade > the bug if he doesn't want the packages to be removed from Jessie. > > Later the security team contacted him about this CVE and asked him to > request an unblock because it would be better to release Jessie without > an open CVE on dolibarr. > > > The diff is very large, and it probably contains lots of changes that > are not > > appropriate at this point of the freeze. If you think this is not the > case, > > please explain why. > > It's certainly the case, but the package is a leaf package and the fixed > version has been well tested in sid. > > The package maintainer is also the upstream author. > > > A targeted fix for this issue is probably better. > > I don't see what a targeted fix brings us given that the only risk of > regression is in dolibarr itself (and Dolibarr is maintained). > > Laurent, what's you opinion? Would you be willing to prepare a targeted > fix? > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: http://www.freexian.com/services/debian-lts.html > Learn to master Debian: http://debian-handbook.info/get/ >
