All of lore.kernel.org
 help / color / mirror / Atom feed
From: akuster <akuster@mvista.com>
To: Sona Sarmadi <sona.sarmadi@enea.com>, Khem Raj <raj.khem@gmail.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: General policies for CVE fixes
Date: Wed, 19 Oct 2016 08:41:05 -0700	[thread overview]
Message-ID: <6b866b61-731b-a7b0-4da1-6f1b25d66528@mvista.com> (raw)
In-Reply-To: <3230301C09DEF9499B442BBE162C5E48ABE9A5A1@SESTOEX04.enea.se>



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



  parent reply	other threads:[~2016-10-19 15:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 19:11 General policies for CVE fixes Sona Sarmadi
2016-10-17 19:23 ` Bruce Ashfield
2016-10-17 21:34   ` Paul Eggleton
2016-10-17 22:41     ` akuster808
2016-10-17 22:53       ` Paul Eggleton
2016-10-17 19:28 ` akuster
2016-10-17 23:01 ` Khem Raj
2016-10-19 10:42   ` Sona Sarmadi
2016-10-19 13:08     ` Bruce Ashfield
2016-10-19 15:41     ` akuster [this message]
2016-10-27  6:23       ` Sona Sarmadi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6b866b61-731b-a7b0-4da1-6f1b25d66528@mvista.com \
    --to=akuster@mvista.com \
    --cc=raj.khem@gmail.com \
    --cc=sona.sarmadi@enea.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.