[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC 1/1] security-process: update process information

From: Red Hat Product Security
Subject: Re: [RFC 1/1] security-process: update process information
Date: Tue, 24 Nov 2020 08:26:58 -0800 (PST)


INC1531976 ([RFC 1/1] security-process: update process information) has been updated.

Opened for: Prasad Pandit
Followers: stefanha@gmail.com, peter.maydell@linaro.org, sstabellini@kernel.org, Petr Matousek, pjp@fedoraproject.org, konrad.wilk@oracle.com, michael.roth@amd.com, mst@redhat.com, qemu-devel@nongnu.org, darren.kenny@oracle.com, Daniel Berrange

A Guest updated your request with the following comments:

Reply from: darren.kenny@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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]