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.