qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 1/1] security-process: update process information


From: Daniel P . Berrangé
Subject: Re: [PATCH v1 1/1] security-process: update process information
Date: Wed, 2 Dec 2020 12:34:18 +0000
User-agent: Mutt/1.14.6 (2020-07-11)

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]