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