Re: [Qemu-devel] [PATCH] MAINTAINERS: addresses for responsible disclosure

[Daniel P. Berrange]

On Mon, Apr 28, 2014 at 02:24:45PM +0100, Peter Maydell wrote:
> On 17 April 2014 19:54, Michael S. Tsirkin <address@hidden> wrote:
> > On Thu, Apr 17, 2014 at 09:10:12AM -0700, Anthony Liguori wrote:
> >> On Thu, Apr 17, 2014 at 6:54 AM, Michael S. Tsirkin <address@hidden> wrote:
> >> > People sometimes detect security issues in upstream
> >> > QEMU and don't know where to report them in a non-public way.
> >> > Of course whoever just wants full disclosure can just go public,
> >> > but there's nothing specified for non-public - until recently Anthony
> >> > was doing this informally.
> >> >
> >> > As I started doing this recently anyway, I can handle this on the QEMU 
> >> > side
> >> > in a more formal way.
> >> >
> >> > Adding a secalert mailing list as well - they are the ones who is 
> >> > actually
> >> > opening CVEs, communicating issues to all downstreams etc,
> >> > and they are already handling this for upstream, not just Red Hat.
> >> >
> >> > Keeping Anthony's address around in case he wants to be informed.
> >> >
> >> > Signed-off-by: Michael S. Tsirkin <address@hidden>
> >>
> >> What about using address@hidden and creating that as a
> >> moderated mailing list with no public archive?
> >>
> >> That way there's a single contact point and there can be many people
> >> backing it up to make sure that disclosures are handled very quickly.
> 
> >
> > Also I'd like a more explicit name, we don't want general
> > security related discussions on that list.
> > address@hidden
> > ?
> 
> OK, so do we want to:
> (a) commit this patch as-is
> (b) set up the proposed mailing list?
> 
> If (b), who has the admin rights to do that?
> 
> I don't feel strongly either way.

Beyond just creating the mailing list and pointing to it in MAINTAINERS,
IMHO it would be a good idea to be explicit about what QEMU's security
handling process is. eg, say what the criteria are for someone to join
the QEMU security mailing list, indicate what you aim for with maximum
embargo times, how / where will issues be announced, what the historic
patch backport policy is, etc. A few months back we documented this kind
of stuff a bit more formally for libvirt:

   http://libvirt.org/securityprocess.html

Also, at the suggestion/request of distro vendor security representatives,
we started using a structured, machine readable document format for
describing security issues. This has also helped us tracking down which
historical branches are vulnerable. We use this to produce a web site
listing all historic libvirt flaws, as well as for generating the text
email announcement text and providing the raw XML for consumption by
downstream vendors. eg so every issue is published in 3 formats:

   http://security.libvirt.org/2014/0001.txt
   http://security.libvirt.org/2014/0001.html
   http://security.libvirt.org/2014/0001.xml

In future we aim to also be able to generate CVRF formatted XML doc, since
that is a commonly used standard schema, but code for that isn't done yet.
If QEMU wishes to re-use any of the scripts libvirt uses for handling these
documents, they are all provided under the GPL:

  http://libvirt.org/git/?p=libvirt-security-notice.git;a=tree

(The XML doc for each issue gets added to that repo when the embargo is
 lifted, and a cron job updates security.libvirt.org from GIT hourly).

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|