qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 :|



  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).