qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] MAINTAINERS: addresses for responsible disclosure
Date: Thu, 17 Apr 2014 17:38:32 +0300

On Thu, Apr 17, 2014 at 03:03:48PM +0100, Peter Maydell wrote:
> On 17 April 2014 14:54, 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.
> 
> This makes sense to me -- as I understand it we've always informally
> leaned on the Red Hat security apparatus, so having it written down
> somewhere so people know who they ought to inform seems like a
> good idea to me.
> 
> We can also write something up on the wiki at some point.

Yes, and once such a page is written it's a good idea to reference it in
MAINTAINERS.

> 
> It might be worth discussing what our general process for
> security fixes is -- in the past we've had both:
>  * fix is quietly committed to git and then announced/posted on
>    the mailing list
>  * fix gets a CVE and patches are posted to the list but not
>    necessarily committed to git

We also had cases where fix got a CVE and downstreams
patched their product, later fix was posted upstream and
committed to git.

But at this point, I plan to just help people with the mechanics.

What me and secalert can do for you is:

opening CVEs
communicating issues to downstreams
give downstreams a bit of time to react
suggest best course of action including some of the above steps

Any of this can happen before making issues public





> > Signed-off-by: Michael S. Tsirkin <address@hidden>
> > ---
> >  MAINTAINERS | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 34b8c3f..713546f 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -52,6 +52,12 @@ General Project Administration
> >  ------------------------------
> >  M: Anthony Liguori <address@hidden>
> >
> > +Responsible Disclosure, Reporting Security Issues
> > +------------------------------
> > +M: Michael S. Tsirkin <address@hidden>
> > +M: Anthony Liguori <address@hidden>
> > +L: address@hidden
> 
> If our process is going to involve direct-commit-of-fixes
> then we probably need more than one committer listed here
> to over for holidays/etc.
> 
> thanks
> -- PMM



reply via email to

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