From: "Daniel P. Berrangé" <berrange@redhat.com>
To: P J P <ppandit@redhat.com>
Cc: peter.maydell@linaro.org,
Stefano Stabellini <sstabellini@kernel.org>,
Petr Matousek <pmatouse@redhat.com>,
Prasad J Pandit <pjp@fedoraproject.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Darren Kenny <darren.kenny@oracle.com>,
Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH v1 1/1] security-process: update process information
Date: Wed, 2 Dec 2020 12:34:18 +0000 [thread overview]
Message-ID: <20201202123418.GH2360260@redhat.com> (raw)
In-Reply-To: <20201130134907.348505-2-ppandit@redhat.com>
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 :|
next prev parent reply other threads:[~2020-12-02 12:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 13:49 [PATCH v1 0/1] security-process: update with mailing list details P J P
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é [this message]
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
2020-12-03 9:43 ` Daniel P. Berrangé
2020-12-02 13:50 ` Philippe Mathieu-Daudé
2020-12-03 5:21 ` P J P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201202123418.GH2360260@redhat.com \
--to=berrange@redhat.com \
--cc=darren.kenny@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pjp@fedoraproject.org \
--cc=pmatouse@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).