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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.