Re: [oe] [meta-oe][dunfell][PATCH 1/5] freerdp: Upgrade to 2.2.0

[Marek Vasut <marex@denx.de>]

On 1/17/22 18:34, Marta Rybczynska wrote:
> On Sun, Jan 16, 2022 at 7:22 PM Marek Vasut <marex@denx.de> wrote:
> 
>> On 1/16/22 19:05, akuster808 wrote:
>>>
>>>
>>> On 1/15/22 7:45 AM, Marek Vasut wrote:
>>>> On 1/15/22 14:43, akuster808 wrote:
>>>>>
>>>>>
>>>>> On 1/11/22 8:57 PM, Marek Vasut wrote:
>>>>>> On 1/12/22 05:42, akuster808 wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/11/22 2:47 PM, Marek Vasut wrote:
>>>>>>>> From: Khem Raj <raj.khem@gmail.com>
>>>>>>>>
>>>>>>>> (cherry picked from commit f751dcf81a18fe817b40e755a2ba3f54a74d1e02)
>>>>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>>>
>>>>>>> And why should I allow this?
>>>>>>
>>>>>> This ... what ? The SoB line or the update ?
>>>>>
>>>>> What is in the update from 2.2.0 to 2.4.1?
>>>>
>>>> This patch updates freerdp from 2.0.0 to 2.2.0 , not from 2.2.0 to
>>>> 2.4.1 , that's a later patch.
>>> I still see new features being added in 2.2.0 so the same statements
>>> apply.  Until the process changes to allow package updates that include
>>> new features and functionality for a LTS branch, I am going to decline
>>> taking this patch series.
>>
>> What about the large amount of CVE fixes and the fact that this is still
>> a stable-2.0 branch update, not upgrade to 3.x , as explained below ?
>>
>>
> Marek,
> Are you able to backport needed fixes to 2.2.x series? This would be
> something
> Armin would likely accept.

I'm not really confident at sifting through the 550 or so patches 
between freerdp 2.0.0 and 2.4.1 and picking out what ought to be CVE 
fixes correctly, so that might end up with even worse result.

We can likely pick the fixes from debian oldstable freerdp, but those 
are also last updated in June 2020, and debian stable is on freerdp 
2.3.0 now.

Also, June 2020 is where freerdp no longer has CVE information in the 
commit messages, for whatever reason.

That's why I think rolling the freerdp forward to latest stable-2.x 
series is the easiest, the CVEs get reliably closed and there shouldn't 
be any API/ABI incompatibility.