Hello! INC1531976 ([RFC 1/1] security-process: update process information) has been updated.
Opened for: Prasad Pandit Followers: stefa...@gmail.com, peter.mayd...@linaro.org, sstabell...@kernel.org, Petr Matousek, p...@fedoraproject.org, konrad.w...@oracle.com, michael.r...@amd.com, m...@redhat.com, qemu-devel@nongnu.org, darren.ke...@oracle.com, Daniel Berrange A Guest updated your request with the following comments: Reply from: darren.ke...@oracle.com Hi Prasad, Thanks for writing this up. I have some comments below on the response steps. On Tuesday, 2020-11-24 at 19:52:38 +0530, P J P wrote: > From: Prasad J Pandit > > We are about to introduce a qemu-security mailing list to report > and triage QEMU security issues. > > Update the QEMU security process web page with new mailing list > and triage details. > > Signed-off-by: Prasad J Pandit > --- > contribute/security-process.md | 105 +++++++++++++++++---------------- > 1 file changed, 55 insertions(+), 50 deletions(-) > > diff --git a/contribute/security-process.md b/contribute/security-process.md > index 1239967..a03092c 100644 > --- a/contribute/security-process.md > +++ b/contribute/security-process.md ... > +## How we respond: > + > +* Steps to triage: > + - Examine and validate the issue details to confirm whether the > + issue is genuine and can be misused for malicious purposes. > + - Determine its worst case impact and severity(Low/M/I/Critical) > + - Negotiate embargo timeline (if required) > + - Request a CVE and open an upstream bug > + - Create an upstream fix patch > + > +* Above security lists are operated by select analysts, maintainers and/or > + representatives from downstream communities. > + > +* List members follow a **responsible disclosure** policy. Any non-public > + information you share about security issues, is kept confidential within the > + respective affiliated companies. Such information shall not be passed on to > + any third parties, including Xen Security Project, without your prior > + permission. > + > +* We aim to triage security issues within maximum of 60 days. I always understood triage to be the initial steps in assessing a bug: - determining if it is a security bug, in this case - then deciding on the severity of it I would not expect triage to include seeing it through to the point where there is a fix as in the steps above and as such that definition of triage should probably have a shorter time frame. At this point, if it is not a security bug, then it should just be logged as any other bug in Qemu, which goes on to qemu-devel then. But, if it is a security bug - then that is when the next steps would be taken, to (not necessarily in this order): - negotiate an embargo (should the predefined 60 days be insufficient) - don't know if you need to mention that this would include downstream in this too, since they will be the ones most likely to need the time to distribute a fix - request a CVE - create a fix for upstream - distros can work on bringing that back into downstream as needed, within the embargo period I do feel that it is worth separating the 2 phases of triage and beyond, but of course that is only my thoughts on it, I'm sure others will have theirs. Thanks, Darren. How can I track and update my request? To respond, reply to this email. You may also create a new email and include the request number (INC1531976) in the subject. Thank you, Product Security Ref:MSG36787539
