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

["Daniel P. Berrange" <berrange@redhat.com>]

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

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|