diff mbox

MAINTAINERS: addresses for responsible disclosure

Message ID 1397742863-17066-1-git-send-email-mst@redhat.com
State New
Headers show

Commit Message

Michael S. Tsirkin April 17, 2014, 1:54 p.m. UTC
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 <mst@redhat.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Andreas Färber April 17, 2014, 2:03 p.m. UTC | #1
Am 17.04.2014 15:54, schrieb Michael S. Tsirkin:
> 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 <mst@redhat.com>
> ---
>  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 <aliguori@amazon.com>
>  
> +Responsible Disclosure, Reporting Security Issues
> +------------------------------
> +M: Michael S. Tsirkin <mst@redhat.com>
> +M: Anthony Liguori <aliguori@amazon.com>
> +L: secalert@redhat.com

I believe that after the QEMU Summit 2012 Anthony wanted to set up a
Wiki page on that. Was that forgotten? If so, we should add one,
otherwise we should make it findable and reference it here via W:.

Thanks for documenting this in MAINTAINERS,

Andreas

> +
>  Guest CPU cores (TCG):
>  ----------------------
>  Alpha
Peter Maydell April 17, 2014, 2:03 p.m. UTC | #2
On 17 April 2014 14:54, Michael S. Tsirkin <mst@redhat.com> 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.

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

> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>  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 <aliguori@amazon.com>
>
> +Responsible Disclosure, Reporting Security Issues
> +------------------------------
> +M: Michael S. Tsirkin <mst@redhat.com>
> +M: Anthony Liguori <aliguori@amazon.com>
> +L: secalert@redhat.com

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
Michael S. Tsirkin April 17, 2014, 2:38 p.m. UTC | #3
On Thu, Apr 17, 2014 at 03:03:48PM +0100, Peter Maydell wrote:
> On 17 April 2014 14:54, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com>
> > ---
> >  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 <aliguori@amazon.com>
> >
> > +Responsible Disclosure, Reporting Security Issues
> > +------------------------------
> > +M: Michael S. Tsirkin <mst@redhat.com>
> > +M: Anthony Liguori <aliguori@amazon.com>
> > +L: secalert@redhat.com
> 
> 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
Anthony Liguori April 17, 2014, 4:10 p.m. UTC | #4
On Thu, Apr 17, 2014 at 6:54 AM, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com>

What about using qemu-security@nongnu.org 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.

Regards,

Anthony Liguori

> ---
>  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 <aliguori@amazon.com>
>
> +Responsible Disclosure, Reporting Security Issues
> +------------------------------
> +M: Michael S. Tsirkin <mst@redhat.com>
> +M: Anthony Liguori <aliguori@amazon.com>
> +L: secalert@redhat.com
> +
>  Guest CPU cores (TCG):
>  ----------------------
>  Alpha
> --
> MST
>
Michael S. Tsirkin April 17, 2014, 6:30 p.m. UTC | #5
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 <mst@redhat.com> 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 <mst@redhat.com>
> 
> What about using qemu-security@nongnu.org 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.
> 
> Regards,
> 
> Anthony Liguori

I prefer to be listed directly, for example some people might
want to use my public key to encrypt the mail.

But I'm not sure we want the list to be moderated - what does this buy us?
We want to make subscriptions limited in some way though -
how is it done?


> > ---
> >  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 <aliguori@amazon.com>
> >
> > +Responsible Disclosure, Reporting Security Issues
> > +------------------------------
> > +M: Michael S. Tsirkin <mst@redhat.com>
> > +M: Anthony Liguori <aliguori@amazon.com>
> > +L: secalert@redhat.com
> > +
> >  Guest CPU cores (TCG):
> >  ----------------------
> >  Alpha
> > --
> > MST
> >
Michael S. Tsirkin April 17, 2014, 6:54 p.m. UTC | #6
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 <mst@redhat.com> 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 <mst@redhat.com>
> 
> What about using qemu-security@nongnu.org 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.
> 
> Regards,
> 
> Anthony Liguori

Also I'd like a more explicit name, we don't want general
security related discussions on that list.
qemu-secalert@nongnu.org

?

> > ---
> >  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 <aliguori@amazon.com>
> >
> > +Responsible Disclosure, Reporting Security Issues
> > +------------------------------
> > +M: Michael S. Tsirkin <mst@redhat.com>
> > +M: Anthony Liguori <aliguori@amazon.com>
> > +L: secalert@redhat.com
> > +
> >  Guest CPU cores (TCG):
> >  ----------------------
> >  Alpha
> > --
> > MST
> >
Peter Maydell April 28, 2014, 1:24 p.m. UTC | #7
On 17 April 2014 19:54, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mst@redhat.com>
>>
>> What about using qemu-security@nongnu.org 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.
> qemu-secalert@nongnu.org
> ?

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.

thanks
-- PMM
Michael S. Tsirkin April 28, 2014, 1:39 p.m. UTC | #8
On Mon, Apr 28, 2014 at 02:24:45PM +0100, Peter Maydell wrote:
> On 17 April 2014 19:54, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mst@redhat.com>
> >>
> >> What about using qemu-security@nongnu.org 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.
> > qemu-secalert@nongnu.org
> > ?
> 
> 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.
> 
> thanks
> -- PMM

Way I see it, as long as it has the same people, it probably doesn't matter :)
We can get around to creating a list if/when more people
volunteer.

I also think we want people to have the option to communicate with pgp.

Some searches I found mailman patches for pgp support:
http://non-gnu.uvt.nl/mailman-pgp-smime/

but without that, we really need to list individual people for now.
Liguori, Anthony April 28, 2014, 1:57 p.m. UTC | #9
https://lists.nongnu.org/mailman/admin/qemu-security

Has been created but it will take 24-48 hours for Savannah to do it's thing.  I'll send out the mailing list password to Michael and Peter once it is created.

Regards,

Anthony Liguori
Daniel P. Berrangé April 28, 2014, 2:25 p.m. UTC | #10
On Mon, Apr 28, 2014 at 02:24:45PM +0100, Peter Maydell wrote:
> On 17 April 2014 19:54, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mst@redhat.com>
> >>
> >> What about using qemu-security@nongnu.org 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.
> > qemu-secalert@nongnu.org
> > ?
> 
> 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
Michael S. Tsirkin April 28, 2014, 2:35 p.m. UTC | #11
I'll play around once I get the password.
From what I've seen so far,
I'm not sure it's the right server to use for security :(

The list now appears here
https://lists.nongnu.org/mailman/listinfo
under the heading "Below is a listing of all the public mailing lists on
lists.nongnu.org."
The list page https://lists.nongnu.org/mailman/listinfo/qemu-security
also seems to even have a link to public archives - it's not live
but its presence might scare people away.

We definitely do not want this list to be public - it's so people who want to do
the responsible disclosure process can get some response and possibly
help.

If someone just wants to go public there's always qemu-devel.

I guess we can configure it to actually be non-public, but hiding
information seems unlikely to be one of savannah's strong points.
I know if I was asked to post sensitive information to such
a list I would hesitate, which isn't the effect we are trying to
achieve here.


On Mon, Apr 28, 2014 at 01:57:26PM +0000, Liguori, Anthony wrote:
> https://lists.nongnu.org/mailman/admin/qemu-security
> 
> Has been created but it will take 24-48 hours for Savannah to do it's thing.  I'll send out the mailing list password to Michael and Peter once it is created.
> 
> Regards,
> 
> Anthony Liguori
> 
> ________________________________________
> From: Michael S. Tsirkin [mst@redhat.com]
> Sent: Monday, April 28, 2014 6:39 AM
> To: Peter Maydell
> Cc: Anthony Liguori; qemu-devel; Stefan Hajnoczi; Andreas Färber; Liguori, Anthony
> Subject: Re: [Qemu-devel] [PATCH] MAINTAINERS: addresses for responsible disclosure
> 
> On Mon, Apr 28, 2014 at 02:24:45PM +0100, Peter Maydell wrote:
> > On 17 April 2014 19:54, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mst@redhat.com>
> > >>
> > >> What about using qemu-security@nongnu.org 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.
> > > qemu-secalert@nongnu.org
> > > ?
> >
> > 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.
> >
> > thanks
> > -- PMM
> 
> Way I see it, as long as it has the same people, it probably doesn't matter :)
> We can get around to creating a list if/when more people
> volunteer.
> 
> I also think we want people to have the option to communicate with pgp.
> 
> Some searches I found mailman patches for pgp support:
> http://non-gnu.uvt.nl/mailman-pgp-smime/
> 
> but without that, we really need to list individual people for now.
> 
> --
> MST
Michael S. Tsirkin April 28, 2014, 5:53 p.m. UTC | #12
On Mon, Apr 28, 2014 at 05:35:38PM +0300, Michael S. Tsirkin wrote:
> I'll play around once I get the password.
> From what I've seen so far,
> I'm not sure it's the right server to use for security :(

I did some more reseach and savannah does not seem to support any
encryption for its lists: neither TLS nor PGP.

This would mean that all communication has to be in the clear.

I think that for this use, we would be better off with an option that
can guarantee a measure of privacy.  For now simply listing specific
addresses and GPG keys looks like the only way.

Makes sense?
I would really like us to get an agreement on this so we can start
making progress on harder issues such as agreeing on a security policy.


> The list now appears here
> https://lists.nongnu.org/mailman/listinfo
> under the heading "Below is a listing of all the public mailing lists on
> lists.nongnu.org."
> The list page https://lists.nongnu.org/mailman/listinfo/qemu-security
> also seems to even have a link to public archives - it's not live
> but its presence might scare people away.
> 
> We definitely do not want this list to be public - it's so people who want to do
> the responsible disclosure process can get some response and possibly
> help.
> 
> If someone just wants to go public there's always qemu-devel.
> 
> I guess we can configure it to actually be non-public, but hiding
> information seems unlikely to be one of savannah's strong points.
> I know if I was asked to post sensitive information to such
> a list I would hesitate, which isn't the effect we are trying to
> achieve here.
> 
> 
> On Mon, Apr 28, 2014 at 01:57:26PM +0000, Liguori, Anthony wrote:
> > https://lists.nongnu.org/mailman/admin/qemu-security
> > 
> > Has been created but it will take 24-48 hours for Savannah to do it's thing.  I'll send out the mailing list password to Michael and Peter once it is created.
> > 
> > Regards,
> > 
> > Anthony Liguori
> > 
> > ________________________________________
> > From: Michael S. Tsirkin [mst@redhat.com]
> > Sent: Monday, April 28, 2014 6:39 AM
> > To: Peter Maydell
> > Cc: Anthony Liguori; qemu-devel; Stefan Hajnoczi; Andreas Färber; Liguori, Anthony
> > Subject: Re: [Qemu-devel] [PATCH] MAINTAINERS: addresses for responsible disclosure
> > 
> > On Mon, Apr 28, 2014 at 02:24:45PM +0100, Peter Maydell wrote:
> > > On 17 April 2014 19:54, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mst@redhat.com>
> > > >>
> > > >> What about using qemu-security@nongnu.org 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.
> > > > qemu-secalert@nongnu.org
> > > > ?
> > >
> > > 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.
> > >
> > > thanks
> > > -- PMM
> > 
> > Way I see it, as long as it has the same people, it probably doesn't matter :)
> > We can get around to creating a list if/when more people
> > volunteer.
> > 
> > I also think we want people to have the option to communicate with pgp.
> > 
> > Some searches I found mailman patches for pgp support:
> > http://non-gnu.uvt.nl/mailman-pgp-smime/
> > 
> > but without that, we really need to list individual people for now.
> > 
> > --
> > MST
Liguori, Anthony April 28, 2014, 9 p.m. UTC | #13
I think this is a bit overkill.  Many projects use private mailing lists for this purpose.

Regards,

Anthony Liguori
Michael S. Tsirkin April 29, 2014, 5:36 a.m. UTC | #14
On Mon, Apr 28, 2014 at 09:00:40PM +0000, Liguori, Anthony wrote:
> I think this is a bit overkill.
Hmm to clarify, this forces people to send info
about 0 day exploits over the internet in cleartext.

What do we get in return for sacrificing the privacy? A small
convenience of not typing in 3 addresses?

>  Many projects use private mailing lists for this purpose.
True that some others do this but frankly I don't understand it.
Maybe this tradeoff starts to make sense if the list of subscribers is
large?


> 
> Regards,
> 
> Anthony Liguori
> 
> ________________________________________
> From: Michael S. Tsirkin [mst@redhat.com]
> Sent: Monday, April 28, 2014 10:53 AM
> To: Liguori, Anthony
> Cc: Peter Maydell; Anthony Liguori; qemu-devel; Stefan Hajnoczi; Andreas Färber
> Subject: Re: [Qemu-devel] [PATCH] MAINTAINERS: addresses for responsible disclosure
> 
> On Mon, Apr 28, 2014 at 05:35:38PM +0300, Michael S. Tsirkin wrote:
> > I'll play around once I get the password.
> > From what I've seen so far,
> > I'm not sure it's the right server to use for security :(
> 
> I did some more reseach and savannah does not seem to support any
> encryption for its lists: neither TLS nor PGP.
> 
> This would mean that all communication has to be in the clear.
> 
> I think that for this use, we would be better off with an option that
> can guarantee a measure of privacy.  For now simply listing specific
> addresses and GPG keys looks like the only way.
> 
> Makes sense?
> I would really like us to get an agreement on this so we can start
> making progress on harder issues such as agreeing on a security policy.
> 
> 
> > The list now appears here
> > https://lists.nongnu.org/mailman/listinfo
> > under the heading "Below is a listing of all the public mailing lists on
> > lists.nongnu.org."
> > The list page https://lists.nongnu.org/mailman/listinfo/qemu-security
> > also seems to even have a link to public archives - it's not live
> > but its presence might scare people away.
> >
> > We definitely do not want this list to be public - it's so people who want to do
> > the responsible disclosure process can get some response and possibly
> > help.
> >
> > If someone just wants to go public there's always qemu-devel.
> >
> > I guess we can configure it to actually be non-public, but hiding
> > information seems unlikely to be one of savannah's strong points.
> > I know if I was asked to post sensitive information to such
> > a list I would hesitate, which isn't the effect we are trying to
> > achieve here.
> >
> >
> > On Mon, Apr 28, 2014 at 01:57:26PM +0000, Liguori, Anthony wrote:
> > > https://lists.nongnu.org/mailman/admin/qemu-security
> > >
> > > Has been created but it will take 24-48 hours for Savannah to do it's thing.  I'll send out the mailing list password to Michael and Peter once it is created.
> > >
> > > Regards,
> > >
> > > Anthony Liguori
> > >
> > > ________________________________________
> > > From: Michael S. Tsirkin [mst@redhat.com]
> > > Sent: Monday, April 28, 2014 6:39 AM
> > > To: Peter Maydell
> > > Cc: Anthony Liguori; qemu-devel; Stefan Hajnoczi; Andreas Färber; Liguori, Anthony
> > > Subject: Re: [Qemu-devel] [PATCH] MAINTAINERS: addresses for responsible disclosure
> > >
> > > On Mon, Apr 28, 2014 at 02:24:45PM +0100, Peter Maydell wrote:
> > > > On 17 April 2014 19:54, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mst@redhat.com>
> > > > >>
> > > > >> What about using qemu-security@nongnu.org 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.
> > > > > qemu-secalert@nongnu.org
> > > > > ?
> > > >
> > > > 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.
> > > >
> > > > thanks
> > > > -- PMM
> > >
> > > Way I see it, as long as it has the same people, it probably doesn't matter :)
> > > We can get around to creating a list if/when more people
> > > volunteer.
> > >
> > > I also think we want people to have the option to communicate with pgp.
> > >
> > > Some searches I found mailman patches for pgp support:
> > > http://non-gnu.uvt.nl/mailman-pgp-smime/
> > >
> > > but without that, we really need to list individual people for now.
> > >
> > > --
> > > MST
Markus Armbruster April 29, 2014, 5:46 a.m. UTC | #15
"Liguori, Anthony" <aliguori@amazon.com> writes:

> I think this is a bit overkill.  Many projects use private mailing
> lists for this purpose.

I guess you're right on the average level of paranoia among people
willing to report security issues, but I'm afraid you might be off on
the 90th percentile.

Besides, an encrypted option should be offered as a matter of general
principle.  Today more than ever.
diff mbox

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 34b8c3f..713546f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -52,6 +52,12 @@  General Project Administration
 ------------------------------
 M: Anthony Liguori <aliguori@amazon.com>
 
+Responsible Disclosure, Reporting Security Issues
+------------------------------
+M: Michael S. Tsirkin <mst@redhat.com>
+M: Anthony Liguori <aliguori@amazon.com>
+L: secalert@redhat.com
+
 Guest CPU cores (TCG):
 ----------------------
 Alpha