Re: [Qemu-devel] QEMU's CVE Procedures

[Gonglei <arei.gonglei@huawei.com>]

On 2015/6/8 21:07, Daniel P. Berrange wrote:
> On Mon, Jun 08, 2015 at 08:44:25PM +0800, Gonglei wrote:
>> On 2015/6/6 6:16, John Snow wrote:
>>> (6) What about qemu-stable?
>>>
>>> Our stable process is somewhat lacking with respect to the CVE
>>> process. It is good that we occasionally publish stable fix roundups
>>> that downstream maintainers can base their work off of, but it would
>>> be good to have a branch where we can have CVE fixes posted promptly.
>>>
>> Good point.
>>
>> In our team, when a CVE fix posted in upstream, we should fix all other Qemu
>> versions manually. Sometimes, the involved files are quite different between
>> different Qemu branches. It's too expensive when you have so many different
>> branches need to maintain. :(
>>
>>>
>>> (7) How long should we support a stable branch?
>>>
>>> We should figure out how many stable release trees we actually intend
>>> to support: The last two releases? The last three?
>>>
>>> My initial guess is "Any stable branch should be managed for at least
>>> a year after initial release."
>>>
>>> This would put our current supported releases as 2.1, 2.2 and 2.3, so
>>> about ~3 managed releases seems sane as an initial effort.
> 
> FWIW, even if QEMU doesn't backport the fix to all branches, I think
> the important this is to document which historical releases are going
> to be affected by the CVE. That gives maintainers a heads up a to
> whether they are going to have to do a backport themselves.
> 
> This is not generally as bad as it sounds, as part of triaging most
> CVEs is to look at GIT history to identify when a flaw was first
> introduced. Once you know that its usually pretty straightforward
> to identify the branches that will be affected. ie all that post
> date that commit, and sometimes earlier releases if the flaw was
> backported.
> 
> For libvirt, we'll generally backport the fix to all -maint branches
> that exist (no matter how old) as long as the patch cherry picks with
> reasonable ease.
> 
> 
> One of the things I could really recommend is to have a formal
> description for all QEMU flaws recording this kind of important
> metadata, along with other relevant metadata.
> 
> In libvirt we store all our records in a git repo, in a standardized
> XML format, eg
> 
>   http://libvirt.org/git/?p=libvirt-security-notice.git;a=blob;f=notices/2015/0002.xml;hb=HEAD
> 

Cool, it's very clear.

Regards,
-Gonglei

> This is then converted to HTML and plain text for publication on our
> website and via email
> 
>    http://security.libvirt.org/2014/0003.html
>    http://security.libvirt.org/2014/0003.txt
>    http://security.libvirt.org/2014/0003.xml
> 
> Notice in particular the list of GIT hashes and release tags identifying
> when the flaw was introduced, what releases are broken, when the flaw
> was fixed (if at all) and when the fix was released (if at all).
> 
> Regards,
> Daniel
>