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 >
