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