Re: [Xen-devel] Coverity + XenProject + Process?

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:
> But there are other folks who I am sure would like to contribute
> and as Coverity is pretty amazing at analyzing issues and providing
> a good idea of how to fix it - was wondering what should be the
> procedure for involving volunteers for that?

Simply triaging the issues into security sensitive and benign issues
would be a great help, even without proposing a fix in either case
(although that would be good too!).

Does coverity support allowing people with access have the ability to
mark an issue as security sensitive or not? If not then it becomes part
of the public list?

Are there safeguards, such as needing 2 or more people need to assert
that the issue is not security sensitive?

> Initially it was recommended that they agree to the security
> disclosure (http://www.xenproject.org/security-policy.html) and
> will agree to use by default the "Two working weeks between issue
> of our advisory to our predisclosure list and publication."

Initially == by me. I thought it might be reasonable to ask people to
give up some of there "discoverer" privileges in return for access to
the list of coverity issues.

We should also probably be explicit that they must disclose to
security@xxxxxxx only and within a reasonable timeframe after diagnosing
the issue, or something.

Do coverity impose any restrictions on the reporting of issues they have
found, in terms of using responsible disclosure etc?

> But I am not sure who should have the power to veto/accept
> volunteers? Should security@xxxxxxx do that? Or should folks
> at Xen Devel mailing list be involved in it as well?

I'd be happier if this was done publicly. Since there is no security
sensitive information at this point there is no reason for it to be
private AFAICT. Maybe the social awkwardness of having people be
publicly turned down is important though?

Wherever they are made I think we need requests to include a short bio
of the person, covering who they are, what their security background is
and why they are interested specifically in the xen project, etc. To aid
us in making a decision as to whether we should trust them.

The request should be signed with a PGP key that is part of the WoT
strong set (i.e. reachable from mine and your keys ).

We could just go with a rule that people need to already be known to the
Xen community (e.g. have submitted a/some patch(es)), but I think there
are plenty of security researchers out there who wouldn't otherwise work
on Xen but might be valuable in this context.

> Should that security disclosure be used for that as well?

What do you mean here?

> Ideas?
> 
> Thank you.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel