General policies for CVE fixes

General policies for CVE fixes

[Sona Sarmadi]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

Hi all,
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.

2)      Normally the versions are different in master and maintenance branches so different patches are required.
Thanks
//Sona

[-- Attachment #2: Type: text/html, Size: 8857 bytes --]

Re: General policies for CVE fixes

[Bruce Ashfield]

On 2016-10-17 03:11 PM, Sona Sarmadi wrote:
> Hi all,
>
> 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?

The kernel has the same policy for -stable kernels. Speaking at a very
high level, it simply ensures that the development of maintenance/stable
branches does not move ahead of master in terms of fixes.

That keeps development focused on the tip, where it belongs (versus
companies/people working in silos for an extended period of time), since
once in master many branches can benefit from it.

>
> 1)      It makes more sense at least for users  to get CVE fixes as soon
> as possible in the maintenance branches.

There's no implied slow down from the process, stable branches can get 
them within hours of changes going into master .. depending on how they
various branches are maintained.

>
> 2)      Normally the versions are different in master and maintenance
> branches so different patches are required.

That's covered in the statement:"unless they are applicable only to the 
stable branch".
Version skew could mean that a fix isn't appropriate to master, but only
to a -stable branch.

But if someone is submitting a CVE fix to -stable, and only to -stable,
they should indicate that the version in master already contains the
fix (or something similar).

Cheers,

Bruce

>
> Thanks
>
> //Sona
>
>
>

Re: General policies for CVE fixes

[akuster]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]



On 10/17/2016 12:11 PM, Sona Sarmadi wrote:
>
> Hi all,
>
> 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?
>
/
This is standard open source policy. The latest version of something 
gets the fix first (if applicable) than is propagated to older versions.

/
>
> 1)It makes more sense at least for users  to get CVE fixes as soon as 
> possible in the maintenance branches.
>
This leads to Master or other newer branches not being fixed.

> 2)Normally the versions are different in master and maintenance 
> branches so different patches are required.
>
Correct.

- Armin
>
> Thanks
>
> //Sona
>
>
>


[-- Attachment #2: Type: text/html, Size: 11805 bytes --]

Re: General policies for CVE fixes

[Paul Eggleton]

On Mon, 17 Oct 2016 15:23:55 Bruce Ashfield wrote:
> On 2016-10-17 03:11 PM, 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?
> 
> The kernel has the same policy for -stable kernels. Speaking at a very
> high level, it simply ensures that the development of maintenance/stable
> branches does not move ahead of master in terms of fixes.
> 
> That keeps development focused on the tip, where it belongs (versus
> companies/people working in silos for an extended period of time), since
> once in master many branches can benefit from it.

Another way to think about this is what would happen if we didn't fix it in 
master first, then forgot to go back and do that? master (and the stable 
release that eventually follows from it) would potentially be left without the 
fix, so when you upgraded the vulnerability would come back.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: General policies for CVE fixes

[akuster808]

On 10/17/2016 02:34 PM, Paul Eggleton wrote:
> On Mon, 17 Oct 2016 15:23:55 Bruce Ashfield wrote:
>> On 2016-10-17 03:11 PM, 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?
>> The kernel has the same policy for -stable kernels. Speaking at a very
>> high level, it simply ensures that the development of maintenance/stable
>> branches does not move ahead of master in terms of fixes.
>>
>> That keeps development focused on the tip, where it belongs (versus
>> companies/people working in silos for an extended period of time), since
>> once in master many branches can benefit from it.
> Another way to think about this is what would happen if we didn't fix it in
> master first, then forgot to go back and do that? master (and the stable
> release that eventually follows from it) would potentially be left without the
> fix, so when you upgraded the vulnerability would come back.
That applies for any fix , security or not.

-armin

>
> Cheers,
> Paul
>

Re: General policies for CVE fixes

[Paul Eggleton]

On Mon, 17 Oct 2016 15:41:04 akuster808 wrote:
> On 10/17/2016 02:34 PM, Paul Eggleton wrote:
> > On Mon, 17 Oct 2016 15:23:55 Bruce Ashfield wrote:
> >> On 2016-10-17 03:11 PM, 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?
> >> 
> >> The kernel has the same policy for -stable kernels. Speaking at a very
> >> high level, it simply ensures that the development of maintenance/stable
> >> branches does not move ahead of master in terms of fixes.
> >> 
> >> That keeps development focused on the tip, where it belongs (versus
> >> companies/people working in silos for an extended period of time), since
> >> once in master many branches can benefit from it.
> > 
> > Another way to think about this is what would happen if we didn't fix it
> > in master first, then forgot to go back and do that? master (and the
> > stable release that eventually follows from it) would potentially be left
> > without the fix, so when you upgraded the vulnerability would come back.
> 
> That applies for any fix , security or not.

Absolutely.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: General policies for CVE fixes

[Khem Raj]

On Mon, Oct 17, 2016 at 12:11 PM, Sona Sarmadi <sona.sarmadi@enea.com> wrote:
> Hi all,
>
> 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.

>
> 2)      Normally the versions are different in master and maintenance
> branches so different patches are required.
>
> Thanks
>
> //Sona
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: General policies for CVE fixes

[Sona Sarmadi]

> > 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?

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

Perhaps we should discuss this at next OEDEM :)

Cheers //Sona

Re: General policies for CVE fixes

[Bruce Ashfield]

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
>

Re: General policies for CVE fixes

[akuster]

On 10/19/2016 03: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?
The issue there is if Jethro gets a fix and Krogoth, morty and mater  
need it as well, the bug system implies someone else is going to have to 
do the work.
That is the problem. Not too many people are stepping up to do the work 
in the other branches.

>
> Maintenance branches are likely deployed in production systems, I think
> Fixing security problems here should have higher priority.
You are more than welcome to submit patches for the stable branch you 
are concerned about knowing the patches wont be applied until the parent 
branches are addressed first.

>   Don't you agree?
>
> Perhaps we should discuss this at next OEDEM :)
We have and until more people step up to help, this will be a constant 
issue.

-armin
>
> Cheers //Sona

Re: General policies for CVE fixes

[Sona Sarmadi]

> > 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?
> The issue there is if Jethro gets a fix and Krogoth, morty and mater need it
> as well, the bug system implies someone else is going to have to do the
> work.
> That is the problem. Not too many people are stepping up to do the work
> in the other branches.
> 
> >
> > Maintenance branches are likely deployed in production systems, I
> > think Fixing security problems here should have higher priority.
> You are more than welcome to submit patches for the stable branch you
> are concerned about knowing the patches wont be applied until the
> parent branches are addressed first.
> 
> >   Don't you agree?
> >
> > Perhaps we should discuss this at next OEDEM :)
> We have and until more people step up to help, this will be a constant
> issue.
> 
> -armin

I see your point, they are absolutely valid.  Thanks.

//Sona