Re: General policies for CVE fixes

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 2016-10-19 06:42 AM, Sona Sarmadi wrote:
>
>>> From https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance:
>>>
>>> General policies:
>>>
>>> Fixes must go into master first unless they are applicable only to the
>>> stable branch; if back-porting to an older stable branch, the fix
>>> should first be applied to the newer stable branches before being
>>> back-ported to the older branch
>>>
>>> Does anyone know the reason for the policy above i.e. why fixes have
>>> to go to master first?
>>>
>>> 1)      It makes more sense at least for users  to get CVE fixes as soon as
>>> possible in the maintenance branches.
>>
>> this is to ensure, that we do not regress next time when we release next
>> version from master. So its important to ensure that the fix has been
>> applied to master sometimes you can assert that the fix has gone into new
>> version of a package that is due to be uprevved in master and will be
>> done soonish. Such information is helpful when making security patches
>> for release branches.
>>
>> Actually there was a suggestion at OEDEM on informing CVE ml that we
>> have as the CVE fixes get applied to metadata. Thats a good suggestion to
>> have implemented.
>
>
> Thanks everyone for your explanation.
>
> Yes regressions (forgetting to fix bugs in master) are bad.  I believe there
> are other ways to avoid this, Yocto project has a bug reporting system to
> have track of such things, right?

Unfortunately, code talks. Unless you strictly follow a procedure like
'master first', you end up with an ever growing list of bugs and
backports. Doing some sort of bulk backport increases the chance of
instability .. not to mention when someone is actively working on an
issue, they have all the context to asses the issue, understand the
change and then fix it in the appropriate branches. If you delay the
backporting by months, you lose that context and the job becomes much
harder.

>
> Maintenance branches are likely deployed in production systems, I think
> Fixing security problems here should have higher priority. Don't you agree?

I wouldn't agree that maintenance branches are any more important for
this than the current tip.

Bruce

>
> Perhaps we should discuss this at next OEDEM :)
>
> Cheers //Sona
>