Re: Wheezy update of ncurses?
On 22/07/17 09:41, Sven Joachim wrote:
> On 2017-07-20 22:32 +0200, Emilio Pozuelo Monfort wrote:
>> On 11/07/17 20:58, Sven Joachim wrote:
>>> On 2017-07-11 10:17 -0400, Roberto C. Sánchez wrote:
>>>> On Sun, Jul 09, 2017 at 03:14:33PM +0100, Chris Lamb wrote:
>>>>> The Debian LTS team would like to fix the security issues which are
>>>>> currently open in the Wheezy version of ncurses:
>>>> All the open ncurses issues are marked no-dsa for jessie and stretch.
>>>> Should we do the same for wheezy?
>>> That would be logical. The bugs only affect the tic program and the tic
>>> library which is used by about three programs in the world (tic, infocmp
>>> and tack), and most of our users never run any of these programs.
>>> Anyway, I have attempted to backport the patches I sent to the release
>>> team (bugs #867814 and #867817). The changes to the library applied
>>> cleanly, but I had to edit progs/dump_entry.c by hand since two hunks
>>> failed to apply there. If anybody wants to upload a fixed package to
>>> wheezy (I won't), please review carefully.
>> Thanks. I have taken a look at this. I have noticed the regression you mentioned
>> on the pu bugs, and so I have tried to backport the termcap-fix.diff.
>> Unfortunately most hunks fail to apply, and applying it manually I noticed the
>> code has changed quite a bit, and as I don't know the code well, I'm worried we
>> may not fix the regression properly or we may cause other issues.
> You are not the only one, I have struggled with this code myself for the
> Jessie upload, in vain so far :-(. The problem is that the regression
> fix relies on additions made in the 20161001 and 20161113 patchlevels,
> and those are pretty large.
> My hope is that a fix might come from Opensuse whose users are already
> suffering from the regression.
>> I wanted to get this fixed as it will be fixed in stretch and jessie, and we
>> don't have a wheezy-proposed-updates suite, and given the comments from the
>> reporter about one bug leading to arbitrary code execution.
> Upstream mentioned that the stack protection would probably prevent such
> an exploit, but I am not a security expert. Attackers would also
> have to trick a victim into running an affected program on their input
> files, not exactly the most profitable social engineering compared to
> sending them (say) a crafted Word or PDF document.
>> But given the risk of not fixing this properly, the few users of the
>> library, the disputed severity of that bug, and that this was tagged
>> no-dsa in the first place, I'm tempted to do that for wheezy too and
>> move on.
> Looks reasonable to me.
Let's do that. I don't think these issues in this tool warrant the update,
specially given the regressions.