| Message ID | 20201130134907.348505-2-ppandit@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | security-process: update with mailing list details | expand |
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.
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
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
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.
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
+-- 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
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
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
+-- 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
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
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 + - 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 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 @@ -48,27 +75,31 @@ of the following steps: ### 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). + +* 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). + +* Members of the security list agree not to publicly disclose any details of + an embargoed security issue until its embargo date expires. ### CVE allocation -An security issue is assigned with a CVE number. The CVE numbers will usually -be allocated by one of the vendor security engineers on the security contact -list. +Each security issue is assigned a [CVE](https://cveform.mitre.org/) number. +The CVE number is allocated by one of the vendor security engineers on the +security list. -## When to contact the QEMU Security Contact List +## When to contact the QEMU Security List -You should contact the Security Contact List if: +You should contact the Security List if: * You think there may be a security vulnerability in QEMU. * You are unsure about how a known vulnerability affects QEMU. * You can contact us in English. We are unable to respond in other languages. -## When *not* to contact the QEMU Security Contact List +## When *not* to contact the QEMU Security List * You need assistance in a language other than English. * You require technical assistance (for example, "how do I configure QEMU?"). * You need help upgrading QEMU due to security alerts. @@ -122,8 +153,3 @@ used to write programs for the SoC device. In such developer environments, it is generally assumed that the guest is trusted. And thus, this buffer overflow turned out to be a security non-issue. - -## What to Send to the QEMU Security Contact List - -Please provide as much information about your system and the issue as possible -when contacting the list.