On Mon, Nov 30, 2020 at 07:19:07PM +0530, P J P wrote: > From: Prasad J Pandit <p...@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 <p...@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 :|