[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 1/1] security-process: update process information
From: |
Darren Kenny |
Subject: |
Re: [RFC 1/1] security-process: update process information |
Date: |
Tue, 24 Nov 2020 16:23:32 +0000 |
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 <pjp@fedoraproject.org>
>
> 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 <pjp@fedoraproject.org>
> ---
> 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.