[Qemu-devel] QEMU's CVE Procedures

[Qemu-devel] QEMU's CVE Procedures

[John Snow]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi, everyone:

("Oh no, what monolith did John type up this time? /Golly Dang He's
really giving Markus a run for his money/")

Prompted by the recent CVE-2015-3456 ("VENOM") issue, it seems to me
that our CVE handling procedure is a little more ad-hoc than it should
reasonably be. This is not the first attempt to help rectify our CVE
process -- see Peter Maydell's 2.3 post-mortem.

Our Security Process page ( http://wiki.qemu.org/SecurityProcess )
details a list of persons one may contact when confronted with a
security issue, but it's not a mailing list of trusted persons, only a
handful of contacts. The only email list mentioned here is actually a
Red Hat list, not an upstream one.


(1) Would it be worth creating an upstream non-public list as a single
point of contact to be able to reach out to? It could include all of
the names printed here (And -- hey! Why is Peter Maydell not on this
list? ...) to make it secure and easy to grab hold of the right people
who understand the security policies.


(2) What is our CVE management policy for maintainers?
This policy page also doesn't specify what maintainers should do or
how they should handle CVEs if they are approached by e.g. the Red Hat
security team, so our policy should expand a little to include
instructions for some of the maintainers and sub-maintainers.

Not that the procedure should be complicated, but spelling it out
can't hurt. Specific policy questions follow below.


(3) How do maintainers get reviews? Who do they ask?
CVEs by nature are handled behind closed doors during the embargo
period, so patches can't just be posted to the list at large. So there
needs to be a review process in place for sub-maintainers that we can
follow to get patches properly reviewed in a secure and private manner
before the embargo date.

We could leave this process "ad-hoc" and trust that maintainers know
who to ask for reviews, but I do not want anyone accused of "slipping
in fixes" away from the eyes of the list, so a more formal procedure
will help prevent any accusations of impropriety.

We likely need a list or mechanism where we can query a portion of
developers who have agreed to assist with CVE patch reviews. This
could include the existing security team, Peter Maydell, other
sub-maintainers, developers with a lot of general experience and/or
experience with the subsystem in question.

This could be perhaps the same email list as above (expanded to
include a couple of reviewers) and those reviewers could loop in other
developers on a case-by-case basis to get appropriate reviews, or we
could create a wiki page with GPG keys and so forth of trusted
reviewers that sub-maintainers can reach out to for reviews on a
case-by-case basis.

Anything would be better than "Guess and go for it."


(4) How much review is sufficient?

A CVE patch should probably get at least one review from someone who
is not Peter Maydell or the subsystem maintainer.

After it's been looked over by these 2-3 people it should be handed
over to Peter Maydell to pre-approve prior to the embargo date being
lifted so that the patch can be pulled promptly after disclosure is
public.


(5) What should be posted on embargo day?

A pull request of the patch(es) with all of the ACKs and R-Bs acquired
during the embargo period alongside the patch being posted to
qemu-devel and qemu-stable simultaneously seems sufficient.

Any additional review or changes incurred after the embargo date can
be handled publicly and in the normal manner in response to the patch.


(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.


(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.


(8) What should our procedure for tagging stable branches be?

I am suggesting that we /can/ and *should* apply bug-fixes to the
stable branches untagged to allow people to check out and build what
are essentially "preview" builds of the upcoming stable release.

Peter has suggested that any CVE patch in particular should force a
new stable tag and cause an accompanying source tarball release
without waiting for a roundup.

This is in contrast to our current rhythm where we only push new
patches periodically as part of the roundup and tag the new stable
release then. This is undesirable because it means that users may not
be able to get bugfixes and security patches in a timely manner from
upstream -- they currently HAVE to rely on downstream maintainers.


(9) Who is going to manage these stable branches?

Currently it looks like Michael Roth, although he's not actually
listed in the MAINTAINERS file. The maintainers file lists a bunch of
apparently unsupported and orphaned stable branches, too -- we should
cull these and update the file with newer information.

Perhaps it would be pertinent (If Michael is unwilling) to give each
stable branch to a different maintainer to help keep the maintenance
burden low. Of course, the more people we ask to manage these
releases, the more complicated each individual CVE becomes, because it
increases the necessary communication between the different stable
branch maintainers.



Anyway, my apologies for the wall of text. I wanted to take this
opportunity post-venom to ask some questions to the list to see if the
interest is there in revamping our CVE policy which is in need of, at
the very least, some clarifications.

See you all next CVE :)

- --js


(Oh, and have a good weekend!)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVch++AAoJEH3vgQaq/DkOiugP/REQCM6H3q7O5CnomtEq0Gtw
WrrQ/8qyCaqRSb6VcO97wO0hQUMEy01SQ1B+HhOzHEWcO1BmhjC0GyNQpAD7JAl6
gRcYpoKa+regPCNc1Sa4eCgI7c8RoC9qygzmrRxgXYI9vGvJn3pideGJB3ubd0ej
uX8SqjxhJKMp7gLnKcBdasYfNTrazvc+8Co5I+VXj68gdSHz+qlw3/Ebgf9FIIez
jHT+jH5t98XlZ1R3zL/iQMKTJDEtrF8zAwW5IZxA3cxcl8dW3K06bWx2RQd59PGB
CQVWCelPg74JiU5d4WX06GiTf863t56K2q0JuO0pGLBhMfP0ILF5CHf9h4lG3bnJ
dtsYMrs45eJfNfQj4C54tRdXN8GVBc0XAih1QCgDP52B+rw28wZNg4CvIyYr3uCV
s9j+0+dtiQ9nX0WIkTs2sCpdhTd3Of3x3Pi/i8FlI7c53mQVoa8hW3wYpUsfnWms
LRyuMjQ0g7oxZMYlWn9XWfgmvGTk3TwP/zKRI9Bh6HqldYqhzJDsz7lzKKJsWuRG
1KFfmJWbAo96uTWFM7p/2UJSGrlN970tU+cpBXpVMsEc8F7xfqup4/6dlqX1ZX0Z
r8u9NP7jwUHcP66ZrtbrHvGOhxQiKjNiGAgXcwJWlDA4rEv90nt9IXBs6hYRd61S
QSlU9M5OTcbyskOmm7lh
=Jepd
-----END PGP SIGNATURE-----

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

On Fri, Jun 05, 2015 at 06:16:30PM -0400, John Snow wrote:
> Anyway, my apologies for the wall of text. I wanted to take this
> opportunity post-venom to ask some questions to the list to see if the
> interest is there in revamping our CVE policy which is in need of, at
> the very least, some clarifications.

Can you post a draft SecurityProcess wiki page that includes your
suggested changes?

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

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

[Stefano Stabellini]

On Fri, 5 Jun 2015, John Snow wrote:
> ----- Topal: Output generated on Mon Jun  8 11:48:03 BST 2015
> ----- Topal: GPG output starts -----
> gpg: Signature made Fri 05 Jun 2015 23:16:30 BST using RSA key ID AAFC390E
> gpg: Can't check signature: public key not found
> ----- Topal: GPG output ends -----
> ----- Topal: Original message starts -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi, everyone:
> 
> ("Oh no, what monolith did John type up this time? /Golly Dang He's
> really giving Markus a run for his money/")
> 
> Prompted by the recent CVE-2015-3456 ("VENOM") issue, it seems to me
> that our CVE handling procedure is a little more ad-hoc than it should
> reasonably be. This is not the first attempt to help rectify our CVE
> process -- see Peter Maydell's 2.3 post-mortem.
> 
> Our Security Process page ( http://wiki.qemu.org/SecurityProcess )
> details a list of persons one may contact when confronted with a
> security issue, but it's not a mailing list of trusted persons, only a
> handful of contacts. The only email list mentioned here is actually a
> Red Hat list, not an upstream one.
> 
> 
> (1) Would it be worth creating an upstream non-public list as a single
> point of contact to be able to reach out to? It could include all of
> the names printed here (And -- hey! Why is Peter Maydell not on this
> list? ...) to make it secure and easy to grab hold of the right people
> who understand the security policies.

+1


> (2) What is our CVE management policy for maintainers?
> This policy page also doesn't specify what maintainers should do or
> how they should handle CVEs if they are approached by e.g. the Red Hat
> security team, so our policy should expand a little to include
> instructions for some of the maintainers and sub-maintainers.
> 
> Not that the procedure should be complicated, but spelling it out
> can't hurt. Specific policy questions follow below.

I think that this is the point that is going to be harder to write. Feel
free to take a look at the Xen security process for inspiration:

http://www.xenproject.org/security-policy.html

Xen maintains its own pre-disclosure list, but aside from that, the rest
should be pretty reusable.


> (3) How do maintainers get reviews? Who do they ask?
> CVEs by nature are handled behind closed doors during the embargo
> period, so patches can't just be posted to the list at large. So there
> needs to be a review process in place for sub-maintainers that we can
> follow to get patches properly reviewed in a secure and private manner
> before the embargo date.
> 
> We could leave this process "ad-hoc" and trust that maintainers know
> who to ask for reviews, but I do not want anyone accused of "slipping
> in fixes" away from the eyes of the list, so a more formal procedure
> will help prevent any accusations of impropriety.
> 
> We likely need a list or mechanism where we can query a portion of
> developers who have agreed to assist with CVE patch reviews. This
> could include the existing security team, Peter Maydell, other
> sub-maintainers, developers with a lot of general experience and/or
> experience with the subsystem in question.
> 
> This could be perhaps the same email list as above (expanded to
> include a couple of reviewers) and those reviewers could loop in other
> developers on a case-by-case basis to get appropriate reviews, or we
> could create a wiki page with GPG keys and so forth of trusted
> reviewers that sub-maintainers can reach out to for reviews on a
> case-by-case basis.
> 
> Anything would be better than "Guess and go for it."

This should be easy: I think that people in the security list should
include anybody they feel would be able to contribute, as long as they
previously agree on the terms of the embargo.


> (4) How much review is sufficient?
> 
> A CVE patch should probably get at least one review from someone who
> is not Peter Maydell or the subsystem maintainer.
> 
> After it's been looked over by these 2-3 people it should be handed
> over to Peter Maydell to pre-approve prior to the embargo date being
> lifted so that the patch can be pulled promptly after disclosure is
> public.
>
> (5) What should be posted on embargo day?
> 
> A pull request of the patch(es) with all of the ACKs and R-Bs acquired
> during the embargo period alongside the patch being posted to
> qemu-devel and qemu-stable simultaneously seems sufficient.
> 
> Any additional review or changes incurred after the embargo date can
> be handled publicly and in the normal manner in response to the patch.
> 
> 
> (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.

+1


> (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.

I would like to see a more formal stance on how long the stable trees
will be maintained. It would also be nice if the trees were maintained
for longer period of times compared to now, without necessarily getting
into the business of maintaining them for years.


> 
> (8) What should our procedure for tagging stable branches be?
> 
> I am suggesting that we /can/ and *should* apply bug-fixes to the
> stable branches untagged to allow people to check out and build what
> are essentially "preview" builds of the upcoming stable release.
> 
> Peter has suggested that any CVE patch in particular should force a
> new stable tag and cause an accompanying source tarball release
> without waiting for a roundup.
> 
> This is in contrast to our current rhythm where we only push new
> patches periodically as part of the roundup and tag the new stable
> release then. This is undesirable because it means that users may not
> be able to get bugfixes and security patches in a timely manner from
> upstream -- they currently HAVE to rely on downstream maintainers.

I am not sure whether a new tag is important, as long as the CVE fixes
are applied to the stable trees right away.



> (9) Who is going to manage these stable branches?
> 
> Currently it looks like Michael Roth, although he's not actually
> listed in the MAINTAINERS file. The maintainers file lists a bunch of
> apparently unsupported and orphaned stable branches, too -- we should
> cull these and update the file with newer information.
> 
> Perhaps it would be pertinent (If Michael is unwilling) to give each
> stable branch to a different maintainer to help keep the maintenance
> burden low. Of course, the more people we ask to manage these
> releases, the more complicated each individual CVE becomes, because it
> increases the necessary communication between the different stable
> branch maintainers.
> 

I am not volunteering for maintaining the QEMU stable trees (not enough
bandwidth), but I am happy to help providing backports, given that most
of the times I need to do that anyway for the qemu-xen stable trees and
they should be reusable as is.


> Anyway, my apologies for the wall of text. I wanted to take this
> opportunity post-venom to ask some questions to the list to see if the
> interest is there in revamping our CVE policy which is in need of, at
> the very least, some clarifications.
> 
> See you all next CVE :)
> 
> - --js
> 
> 
> (Oh, and have a good weekend!)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJVch++AAoJEH3vgQaq/DkOiugP/REQCM6H3q7O5CnomtEq0Gtw
> WrrQ/8qyCaqRSb6VcO97wO0hQUMEy01SQ1B+HhOzHEWcO1BmhjC0GyNQpAD7JAl6
> gRcYpoKa+regPCNc1Sa4eCgI7c8RoC9qygzmrRxgXYI9vGvJn3pideGJB3ubd0ej
> uX8SqjxhJKMp7gLnKcBdasYfNTrazvc+8Co5I+VXj68gdSHz+qlw3/Ebgf9FIIez
> jHT+jH5t98XlZ1R3zL/iQMKTJDEtrF8zAwW5IZxA3cxcl8dW3K06bWx2RQd59PGB
> CQVWCelPg74JiU5d4WX06GiTf863t56K2q0JuO0pGLBhMfP0ILF5CHf9h4lG3bnJ
> dtsYMrs45eJfNfQj4C54tRdXN8GVBc0XAih1QCgDP52B+rw28wZNg4CvIyYr3uCV
> s9j+0+dtiQ9nX0WIkTs2sCpdhTd3Of3x3Pi/i8FlI7c53mQVoa8hW3wYpUsfnWms
> LRyuMjQ0g7oxZMYlWn9XWfgmvGTk3TwP/zKRI9Bh6HqldYqhzJDsz7lzKKJsWuRG
> 1KFfmJWbAo96uTWFM7p/2UJSGrlN970tU+cpBXpVMsEc8F7xfqup4/6dlqX1ZX0Z
> r8u9NP7jwUHcP66ZrtbrHvGOhxQiKjNiGAgXcwJWlDA4rEv90nt9IXBs6hYRd61S
> QSlU9M5OTcbyskOmm7lh
> =Jepd
> -----END PGP SIGNATURE-----
> ----- Topal: Original message ends -----
> 

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

[Gonglei]

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.

Regards,
-Gonglei

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

[Daniel P. Berrange]

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

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

[Peter Maydell]

On 5 June 2015 at 23:16, John Snow <jsnow@redhat.com> wrote:
> Prompted by the recent CVE-2015-3456 ("VENOM") issue, it seems to me
> that our CVE handling procedure is a little more ad-hoc than it should
> reasonably be. This is not the first attempt to help rectify our CVE
> process -- see Peter Maydell's 2.3 post-mortem.

Thanks for raising this. Rather than trying to fit my opinions
into a per-para response format I'll just list some general
principles/opinions first:

 (1) We shouldn't set ourselves a security policy we don't have
     the resources to actually adhere to
 (2) We should be clear about what we actually are guaranteeing
     (both to end-users and to people reporting vulnerabilities)
 (3) We should try to avoid an excessively formal and prescriptive
     security policy/process
 (4) I think the lack of timely upstream tarball releases with
     security fixes is the biggest problem with our current setup
     (it basically means we're saying "if you care about guest
     isolation then use a distro QEMU, or monitor CVE lists and
     backport patches yourself")

> (1) Would it be worth creating an upstream non-public list as a single
> point of contact to be able to reach out to? It could include all of
> the names printed here (And -- hey! Why is Peter Maydell not on this
> list? ...) to make it secure and easy to grab hold of the right people
> who understand the security policies.

We went back and forth on this one when we set up that page; see
this thread from last year:
https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg02724.html
There was concern that using a mailing list would clash with people
being able to use PGP to send us info about vulnerabilities.
I don't personally have a strong opinion (except for "using
GPG for email is a huge pain in the neck", that's a fairly
strong opinion).

The reason I'm not on the list of people notified is that
I don't have any desire to be in the first-line triage of
genuine vulnerabilities from misapprehension, user error,
non-problems and plain old spam. Having a single person as
"head developer" who has to have their fingers in every pie
is a recipe for burnout and that person leaving the project.

> (2) What is our CVE management policy for maintainers?
> This policy page also doesn't specify what maintainers should do or
> how they should handle CVEs if they are approached by e.g. the Red Hat
> security team, so our policy should expand a little to include
> instructions for some of the maintainers and sub-maintainers.

Yes; we should also perhaps mention in our page for people
disclosing vulnerabilities that we'll inform the relevant
QEMU submaintainer(s) as part of our response.

> (5) What should be posted on embargo day?
>
> A pull request of the patch(es) with all of the ACKs and R-Bs acquired
> during the embargo period alongside the patch being posted to
> qemu-devel and qemu-stable simultaneously seems sufficient.

The other way round you could do it is to apply directly to
master (and stable branches) first, and then post the patches
second. That's the way round that Anthony used to do it. It
has the advantage that there is less delay before the fixes
go into master.

> (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.

Yes, and (as you note below) my ideal would be that any CVE results
in a new stable release, so we don't have the current situation
where our download page only has a 2.0 which still has various
vulnerabilities in.

However, this is where we run sharply into the "do we have the
resources to do this" question. I don't currently maintain the
stable branches and would prefer not to start...

I like Daniel's suggestion about documenting CVE issues.

I'm unconvinced about importing the Xen security policy
wholesale -- I think it is a lot more heavyweight than we
want, since we don't have a commercial company providing
people to deal with CVEs, or direct customers wanting early
notification.

We should probably write down somewhere what we consider to be
a security issue -- something like "only KVM, only <list of
architectures>, only <list of board models>".

thanks
-- PMM

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

[Gonglei]

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
> 

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