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

[Daniel P. Berrange]

On Tue, Jun 09, 2015 at 09:30:11AM +0800, Gonglei wrote:
> 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.

BTW, the tools for converting the data formats and generating
the website index are all in the repo too, GPLv2+ licensed,
so anyone should feel free to reuse them as needed

http://libvirt.org/git/?p=libvirt-security-notice.git;a=tree;f=scripts;hb=HEAD

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