* Re: [PATCH v1 1/1] security-process: update process information
2020-11-30 13:49 ` [PATCH v1 1/1] security-process: update process information P J P
@ 2020-12-01 19:49 ` Konrad Rzeszutek Wilk
2020-12-02 12:19 ` P J P
2020-12-02 12:34 ` Daniel P. Berrangé
2020-12-02 13:50 ` Philippe Mathieu-Daudé
2 siblings, 1 reply; 12+ messages in thread
From: Konrad Rzeszutek Wilk @ 2020-12-01 19:49 UTC (permalink / raw)
To: P J P
Cc: peter.maydell, Stefano Stabellini, Petr Matousek, Prasad J Pandit,
Michael S . Tsirkin, Stefan Hajnoczi, QEMU Developers,
Darren Kenny, Michael Roth, Daniel P . Berrangé
On Mon, Nov 30, 2020 at 07:19:07PM +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>
Thank you for doing it!
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
with one change below.
> ---
> contribute/security-process.md | 134 ++++++++++++++++++++-------------
> 1 file changed, 80 insertions(+), 54 deletions(-)
>
> Update v1: incorporate feedback from review to include more details
> -> https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg06234.html
>
> diff --git a/contribute/security-process.md b/contribute/security-process.md
> index 1239967..fe1bc8b 100644
> --- a/contribute/security-process.md
> +++ b/contribute/security-process.md
> @@ -3,43 +3,70 @@ title: Security Process
> permalink: /contribute/security-process/
> ---
>
> -QEMU takes security very seriously, and we aim to take immediate action to
> -address serious security-related problems that involve our product.
> -
> -Please report any suspected security vulnerability in QEMU to the following
> -addresses. You can use GPG keys for respective receipients to communicate with
> -us securely. If you do, please upload your GPG public key or supply it to us
> -in some other way, so that we can communicate to you in a secure way, too!
> -Please include the tag **\[QEMU-SECURITY\]** on the subject line to help us
> -identify your message as security-related.
> -
> -## QEMU Security Contact List
> -
> -Please copy everyone on this list:
> -
> - Contact Person(s) | Contact Address | Company | GPG Key | GPG key fingerprint
> -:-----------------------|:------------------------------|:--------------|:---------:|:--------------------
> - Michael S. Tsirkin | mst@redhat.com | Red Hat Inc. | [🔑](https://pgp.mit.edu/pks/lookup?op=vindex&search=0xC3503912AFBE8E67) | 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
> - Petr Matousek | pmatouse@redhat.com | Red Hat Inc. | [🔑](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3E786F42C44977CA) | 8107 AF16 A416 F9AF 18F3 D874 3E78 6F42 C449 77CA
> - Stefano Stabellini | sstabellini@kernel.org | Independent | [🔑](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x894F8F4870E1AE90) | D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90
> - Security Response Team | secalert@redhat.com | Red Hat Inc. | [🔑](https://access.redhat.com/site/security/team/contact/#contact) |
> - Michael Roth | michael.roth@amd.com | AMD | [🔑](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3353C9CEF108B584) | CEAC C9E1 5534 EBAB B82D 3FA0 3353 C9CE F108 B584
> - Prasad J Pandit | pjp@redhat.com | Red Hat Inc. | [🔑](http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=0xE2858B5AF050DE8D) | 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
> -
> -## How to Contact Us Securely
> -
> -We use GNU Privacy Guard (GnuPG or GPG) keys to secure communications. Mail
> -sent to members of the list can be encrypted with public keys of all members
> -of the list. We expect to change some of the keys we use from time to time.
> -Should a key change, the previous one will be revoked.
> -
> -## How we respond
> -
> -Maintainers listed on the security reporting list operate a policy of
> -responsible disclosure. As such they agree that any information you share with
> -them about security issues that are not public knowledge is kept confidential
> -within respective affiliated companies. It is not passed on to any third-party,
> -including Xen Security Project, without your permission.
> +Please report any suspected security issue in QEMU to the security mailing
> +list at:
> +
> +* [\<qemu-security@nongnu.org\>](https://lists.gnu.org/archive/html/qemu-security/)
> +
> +To report an issue via [GPG](https://gnupg.org/) encrypted email, please send
> +it to the Red Hat Product Security team at:
> +
> +* [\<secalert@redhat.com\>](https://access.redhat.com/security/team/contact/#contact)
> +
> +**Note:** after the triage, encrypted issue details shall be sent to the upstream
> +'qemu-security' mailing list for archival purposes.
> +
> +## How to report an issue:
> +
> +* Please include as many details as possible in the issue report.
> + Ex:
> + - QEMU version, upstream commit/tag
> + - Host & Guest architecture x86/Arm/PPC, 32/64 bit etc.
> + - Affected code area/snippets
> + - Stack traces, crash details
> + - Malicious inputs/reproducer steps etc.
> + - Any configurations/settings required to trigger the issue.
> +
> +* Please share the QEMU command line used to invoke a guest VM.
> +
> +* Please specify whom to acknowledge for reporting this issue.
> +
> +## How we respond:
> +
> +* Process of handling security issues can be divided in two halves.
> +
> + 1) **Triage:**
> + - Examine the issue details and confirm whether the issue is genuine
> + - Validate if it can be misused for malicious purposes
> + - Determine its worst case impact and severity
> + [Low/Moderate/Important/Critical]
> +
> + 2) **Response:**
> + - Negotiate embargo timeline (if required, depending on severity)
> + - Request a CVE and open an upstream
> + [bug](https://bugs.launchpad.net/qemu/+bug/)
> + or a [GitLab](https://gitlab.com/groups/qemu-project/-/issues) issue
You may want to clarify that this step in the process will not disclose the details of the
issue to the public.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] security-process: update process information
2020-12-01 19:49 ` Konrad Rzeszutek Wilk
@ 2020-12-02 12:19 ` P J P
0 siblings, 0 replies; 12+ messages in thread
From: P J P @ 2020-12-02 12:19 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: peter.maydell, Stefano Stabellini, Petr Matousek,
Michael S . Tsirkin, Stefan Hajnoczi, QEMU Developers,
Darren Kenny, Michael Roth, Daniel P . Berrangé
Hello Konrad, all
+-- On Tue, 1 Dec 2020, Konrad Rzeszutek Wilk wrote --+
| On Mon, Nov 30, 2020 at 07:19:07PM +0530, P J P wrote:
| > 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.
|
| Thank you for doing it!
| Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thank you.
| with one change below.
|
| > + - Request a CVE and open an upstream
| > + [bug](https://bugs.launchpad.net/qemu/+bug/)
| > + or a [GitLab](https://gitlab.com/groups/qemu-project/-/issues) issue
|
| You may want to clarify that this step in the process will not disclose the
| details of the issue to the public.
Yes, this is covered in the following process text and under publication
embargo section:
===
+ * We aim to process ... 60 days ... After the triaging step above
+
+ - If issue is found to be less severe, an upstream public bug (or an
+ issue) will be created immediately.
+ - If issue is found to be severe, an embargo process below is followed,
+ and public bug (or an issue) will be opened at the end of the set
+ embargo period.
...
+* Embargo periods will be negotiated by mutual agreement between reporter(s),
+ members of the security list and other relevant parties to the problem.
+ Such embargo period is generally upto [2 weeks]
+
+* Members of the security list agree not to publicly disclose any details of
+ an embargoed security issue until its embargo date expires.
===
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] security-process: update process information
2020-11-30 13:49 ` [PATCH v1 1/1] security-process: update process information P J P
2020-12-01 19:49 ` Konrad Rzeszutek Wilk
@ 2020-12-02 12:34 ` Daniel P. Berrangé
2020-12-03 3:29 ` Stefano Stabellini
` (2 more replies)
2020-12-02 13:50 ` Philippe Mathieu-Daudé
2 siblings, 3 replies; 12+ messages in thread
From: Daniel P. Berrangé @ 2020-12-02 12:34 UTC (permalink / raw)
To: P J P
Cc: peter.maydell, Stefano Stabellini, Petr Matousek, Prasad J Pandit,
Michael S . Tsirkin, Stefan Hajnoczi, Konrad Rzeszutek Wilk,
QEMU Developers, Darren Kenny, Michael Roth
On Mon, Nov 30, 2020 at 07:19:07PM +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 | 134 ++++++++++++++++++++-------------
> 1 file changed, 80 insertions(+), 54 deletions(-)
> +* 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.
Why this explicit note about the Xen project ? What if we decide to want
a member of the Xen security team on the QEMU security mailing list so that
we can collaborate on triage ?
Perhaps
Any non-public information you share about security issues, is kept
confidential between members of the QEMU security team, and a minimal
number of supporting staff in their affliated companies. Information
will not be disclosed to other third party organizations/individuals
without prior permission from the reporter
> +* We aim to process security issues within maximum of **60 days**. That is not
> + to say that issues will remain private for 60 days, nope. After the triaging
> + step above
> + - If issue is found to be less severe, an upstream public bug (or an
> + issue) will be created immediately.
No need to repeat "or an issue". I think it would read more clearly as
- If the severity of the issue is sufficiently low, an upstream public bug
may be created immediately.
> + - If issue is found to be severe, an embargo process below is followed,
> + and public bug (or an issue) will be opened at the end of the set
> + embargo period.
- If the severity of the issue requires co-ordinated disclosure at a future
date, then the embargo process below is followed, and public bug will be
opened at the end of the set embargo period.
Somewhere around here is probably a good place to link to:
https://www.qemu.org/docs/master/system/security.html
which describes why we'll consider some things to be not security issues
> ### Publication embargo
>
> -If a security issue is reported that is not already publicly disclosed, an
> -embargo date may be assigned and communicated to the reporter. Embargo
> -periods will be negotiated by mutual agreement between members of the security
> -team and other relevant parties to the problem. Members of the security contact
> -list agree not to publicly disclose any details of the security issue until
> -the embargo date expires.
> +* If a security issue is reported that is not already public and is severe
> + enough, an embargo date may be assigned and communicated to the
> + reporter(s).
* If a security issue is reported that is not already public and its
severity requires coordinated disclosure, an embargo date may be
assigned and communicated to the reporter(s).
> +* Embargo periods will be negotiated by mutual agreement between reporter(s),
> + members of the security list and other relevant parties to the problem.
> + Such embargo period is generally upto [2 weeks](https://oss-security.openwall.org/wiki/mailing-lists/distros).
"The preferred embargo period will be upto 2 weeks, however, longer
embargoes can be negotiated if the severity of the issues requires it."
> +
> +* Members of the security list agree not to publicly disclose any details of
> + an embargoed security issue until its embargo date expires.
>
> ### CVE allocation
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] security-process: update process information
2020-12-02 12:34 ` Daniel P. Berrangé
@ 2020-12-03 3:29 ` Stefano Stabellini
2020-12-03 5:36 ` P J P
2020-12-03 5:22 ` P J P
2020-12-03 6:02 ` P J P
2 siblings, 1 reply; 12+ messages in thread
From: Stefano Stabellini @ 2020-12-03 3:29 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: peter.maydell, Stefano Stabellini, Petr Matousek, Prasad J Pandit,
Michael S . Tsirkin, Stefan Hajnoczi, Konrad Rzeszutek Wilk,
QEMU Developers, P J P, Darren Kenny, Michael Roth
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]
On Wed, 2 Dec 2020, Daniel P. Berrangé wrote:
> On Mon, Nov 30, 2020 at 07:19:07PM +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 | 134 ++++++++++++++++++++-------------
> > 1 file changed, 80 insertions(+), 54 deletions(-)
>
> > +* 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.
>
> Why this explicit note about the Xen project ? What if we decide to want
> a member of the Xen security team on the QEMU security mailing list so that
> we can collaborate on triage ?
Hi Daniel,
this is not an issue because the individual (probably me) of course
would not report anything to the Xen security team without prior
permission.
Also note that the Xen case is one of the easiest because the Xen
security policy gives full powers to the discoverer: the discoverer
chooses both when to disclose and to whom and the Xen security team will
abide.
> Perhaps
>
> Any non-public information you share about security issues, is kept
> confidential between members of the QEMU security team, and a minimal
> number of supporting staff in their affliated companies. Information
> will not be disclosed to other third party organizations/individuals
> without prior permission from the reporter
Sounds good to me
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] security-process: update process information
2020-12-03 3:29 ` Stefano Stabellini
@ 2020-12-03 5:36 ` P J P
0 siblings, 0 replies; 12+ messages in thread
From: P J P @ 2020-12-03 5:36 UTC (permalink / raw)
To: Stefano Stabellini
Cc: peter.maydell, Petr Matousek, Michael S . Tsirkin,
Stefan Hajnoczi, Konrad Rzeszutek Wilk, QEMU Developers,
Darren Kenny, Michael Roth, Daniel P. Berrangé
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
Hello Dan, Stefano,
+-- On Wed, 2 Dec 2020, Stefano Stabellini wrote --+
| On Wed, 2 Dec 2020, Daniel P. Berrangé wrote:
| > > + any third parties, including Xen Security Project, without your prior
| > > + permission.
| >
| > Why this explicit note about the Xen project ? What if we decide to want
| > a member of the Xen security team on the QEMU security mailing list so that
| > we can collaborate on triage ?
* While that's fair point, what I think it means is, even if members from
other communities are present on the qemu-security list, any explicit
communication and/or sharing of issue details/information/reproducers etc.
across communities, with non-members will not happen without prior
permission from the reporter(s).
* Besides, that is not new text, it is from the current process page
-> https://www.qemu.org/contribute/security-process/
| this is not an issue because the individual (probably me) of course
| would not report anything to the Xen security team without prior
| permission.
+1000..., appreciate it.:)
| > Any non-public information you share about security issues, is kept
| > confidential between members of the QEMU security team, and a minimal
| > number of supporting staff in their affliated companies. Information
| > will not be disclosed to other third party organizations/individuals
| > without prior permission from the reporter
|
| Sounds good to me
Same here, will fix it.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] security-process: update process information
2020-12-02 12:34 ` Daniel P. Berrangé
2020-12-03 3:29 ` Stefano Stabellini
@ 2020-12-03 5:22 ` P J P
2020-12-03 6:02 ` P J P
2 siblings, 0 replies; 12+ messages in thread
From: P J P @ 2020-12-03 5:22 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: peter.maydell, Stefano Stabellini, Petr Matousek,
Michael S . Tsirkin, Stefan Hajnoczi, Konrad Rzeszutek Wilk,
QEMU Developers, Darren Kenny, Michael Roth
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
Hello Dan,
+-- On Wed, 2 Dec 2020, Daniel P. Berrangé wrote --+
| > + - If issue is found to be less severe, an upstream public bug (or an
| > + issue) will be created immediately.
|
| No need to repeat "or an issue". I think it would read more clearly as
|
| - If the severity of the issue is sufficiently low, an upstream public bug
| may be created immediately.
Okay.
| > + - If issue is found to be severe, an embargo process below is followed,
| > + and public bug (or an issue) will be opened at the end of the set
| > + embargo period.
|
| - If the severity of the issue requires co-ordinated disclosure at a future
| date, then the embargo process below is followed, and public bug will be
| opened at the end of the set embargo period.
Okay.
| Somewhere around here is probably a good place to link to:
|
| https://www.qemu.org/docs/master/system/security.html
|
| which describes why we'll consider some things to be not security issues
Towards the end, there's a section about 'How impact & severity of an issue
is decided', above link will fit in there good I think.
| > -If a security issue is reported that is not already publicly disclosed, an
| > -embargo date may be assigned and communicated to the reporter. Embargo
| > -periods will be negotiated by mutual agreement between members of the security
| > -team and other relevant parties to the problem. Members of the security contact
| > -list agree not to publicly disclose any details of the security issue until
| > -the embargo date expires.
| > +* If a security issue is reported that is not already public and is severe
| > + enough, an embargo date may be assigned and communicated to the
| > + reporter(s).
|
|
| * If a security issue is reported that is not already public and its
| severity requires coordinated disclosure, an embargo date may be
| assigned and communicated to the reporter(s).
...
| "The preferred embargo period will be upto 2 weeks, however, longer
| embargoes can be negotiated if the severity of the issues requires it."
Okay, will add above changes.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] security-process: update process information
2020-12-02 12:34 ` Daniel P. Berrangé
2020-12-03 3:29 ` Stefano Stabellini
2020-12-03 5:22 ` P J P
@ 2020-12-03 6:02 ` P J P
2020-12-03 9:43 ` Daniel P. Berrangé
2 siblings, 1 reply; 12+ messages in thread
From: P J P @ 2020-12-03 6:02 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: peter.maydell, Stefano Stabellini, Petr Matousek,
Michael S . Tsirkin, Stefan Hajnoczi, Konrad Rzeszutek Wilk,
QEMU Developers, Darren Kenny, Michael Roth
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
+-- On Wed, 2 Dec 2020, Daniel P. Berrangé wrote --+
| > + - If issue is found to be less severe, an upstream public bug (or an
| > + issue) will be created immediately.
|
| No need to repeat "or an issue". I think it would read more clearly as
|
| - If the severity of the issue is sufficiently low, an upstream public bug
| may be created immediately.
* Let's settle on public GitLab issues, shall we?
* Tomorrow after an issue triage if someone asks where should they create a
public tracker, it's better to have one definite answer, instead of choose
either LaunchPad or GitLab issues.
* OR is it better to have both? ie. file a public tracker anywhere as per ones
convenience?
* One GitLab is good I think.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] security-process: update process information
2020-12-03 6:02 ` P J P
@ 2020-12-03 9:43 ` Daniel P. Berrangé
0 siblings, 0 replies; 12+ messages in thread
From: Daniel P. Berrangé @ 2020-12-03 9:43 UTC (permalink / raw)
To: P J P
Cc: peter.maydell, Stefano Stabellini, Petr Matousek,
Michael S . Tsirkin, Stefan Hajnoczi, Konrad Rzeszutek Wilk,
QEMU Developers, Darren Kenny, Michael Roth
On Thu, Dec 03, 2020 at 11:32:44AM +0530, P J P wrote:
> +-- On Wed, 2 Dec 2020, Daniel P. Berrangé wrote --+
> | > + - If issue is found to be less severe, an upstream public bug (or an
> | > + issue) will be created immediately.
> |
> | No need to repeat "or an issue". I think it would read more clearly as
> |
> | - If the severity of the issue is sufficiently low, an upstream public bug
> | may be created immediately.
>
> * Let's settle on public GitLab issues, shall we?
>
> * Tomorrow after an issue triage if someone asks where should they create a
> public tracker, it's better to have one definite answer, instead of choose
> either LaunchPad or GitLab issues.
>
> * OR is it better to have both? ie. file a public tracker anywhere as per ones
> convenience?
>
> * One GitLab is good I think.
Just link to the page where QEMU documents its bug tracker. That is
current laucnhpad, but may change to Gitlab. The security docs don't
need to mention the specific host, if we just link to the bugs page.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] security-process: update process information
2020-11-30 13:49 ` [PATCH v1 1/1] security-process: update process information P J P
2020-12-01 19:49 ` Konrad Rzeszutek Wilk
2020-12-02 12:34 ` Daniel P. Berrangé
@ 2020-12-02 13:50 ` Philippe Mathieu-Daudé
2020-12-03 5:21 ` P J P
2 siblings, 1 reply; 12+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-12-02 13:50 UTC (permalink / raw)
To: P J P, Stefan Hajnoczi
Cc: peter.maydell, Stefano Stabellini, Petr Matousek, Prasad J Pandit,
Michael S . Tsirkin, Michael Roth, Konrad Rzeszutek Wilk,
QEMU Developers, Darren Kenny, Daniel P . Berrangé
Hi Prasad,
On 11/30/20 2:49 PM, P J P wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
...
> +## How we respond:
> +
> +* Process of handling security issues can be divided in two halves.
> +
Maybe:
0) **Acknowledge reception**
- A non-automated response email is sent to acknowledge the
reception of the request.
This is the starting date for the maximum **60 days** required
to process the issue, including bullets 1) and 2).
> + 1) **Triage:**
> + - Examine the issue details and confirm whether the issue is genuine
> + - Validate if it can be misused for malicious purposes
> + - Determine its worst case impact and severity
> + [Low/Moderate/Important/Critical]
> +
> + 2) **Response:**
> + - Negotiate embargo timeline (if required, depending on severity)
> + - Request a CVE and open an upstream
> + [bug](https://bugs.launchpad.net/qemu/+bug/)
> + or a [GitLab](https://gitlab.com/groups/qemu-project/-/issues) issue
> + - Create an upstream fix patch
with the proper Buglink/CVE/Reported-by tags.
- Participate in the review process until the patch is merged.
Test the fix updates with the private reproducer if required.
- Close the upstream [bug] with 'Fix released', including the
commit SHA-1 of the fix.
> +
> +* 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 process security issues within maximum of **60 days**. That is not
> + to say that issues will remain private for 60 days, nope. After the triaging
> + step above
> + - If issue is found to be less severe, an upstream public bug (or an
> + issue) will be created immediately.
> + - If issue is found to be severe, an embargo process below is followed,
> + and public bug (or an issue) will be opened at the end of the set
> + embargo period.
> +
> + This will allow upstream contributors to create, test and track fix patch(es).
>
> Email sent to us is read and acknowledged with a non-automated response. For
> issues that are complicated and require significant attention, we will open an
^^^ You can remove that, as now covered by bullet 0).
Regards,
Phil.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] security-process: update process information
2020-12-02 13:50 ` Philippe Mathieu-Daudé
@ 2020-12-03 5:21 ` P J P
0 siblings, 0 replies; 12+ messages in thread
From: P J P @ 2020-12-03 5:21 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: peter.maydell, Stefano Stabellini, Petr Matousek,
Michael S . Tsirkin, Stefan Hajnoczi, Konrad Rzeszutek Wilk,
QEMU Developers, Darren Kenny, Michael Roth,
Daniel P . Berrangé
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
+-- On Wed, 2 Dec 2020, Philippe Mathieu-Daudé wrote --+
| Maybe:
|
| 0) **Acknowledge reception**
| - A non-automated response email is sent to acknowledge the
| reception of the request.
| This is the starting date for the maximum **60 days** required
| to process the issue, including bullets 1) and 2).
|
| > + - Create an upstream fix patch
|
| with the proper Buglink/CVE/Reported-by tags.
|
| - Participate in the review process until the patch is merged.
| Test the fix updates with the private reproducer if required.
| - Close the upstream [bug] with 'Fix released', including the
| commit SHA-1 of the fix.
...
| > Email sent to us is read and acknowledged with a non-automated response. For
| > issues that are complicated and require significant attention, we will open an
|
| ^^^ You can remove that, as now covered by bullet 0).
Okay, will do. Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 12+ messages in thread