From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z28NM-0002Vs-Jf for qemu-devel@nongnu.org; Mon, 08 Jun 2015 21:30:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z28ND-000220-Ps for qemu-devel@nongnu.org; Mon, 08 Jun 2015 21:30:48 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:20119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z28NC-0001ua-5z for qemu-devel@nongnu.org; Mon, 08 Jun 2015 21:30:39 -0400 Message-ID: <557641A3.4010608@huawei.com> Date: Tue, 9 Jun 2015 09:30:11 +0800 From: Gonglei MIME-Version: 1.0 References: <55721FBE.2010304@redhat.com> <55758E29.5050902@huawei.com> <20150608130705.GB19157@redhat.com> In-Reply-To: <20150608130705.GB19157@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QEMU's CVE Procedures List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Peter Maydell , Stefano Stabellini , Markus Armbruster , "Michael S. Tsirkin" , Michael Roth , qemu-devel , Paolo Bonzini , John Snow 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 >