Xen project Mailing List

Seems to me that it would make sense to condense the discussion into a concrete proposal for review and voting. Although I am not sure that all questions raised in this thread, in particular those related to "can we mark issues related to security and create a published Coverity report that excludes security risks". From what I can see, reports are only visible via https://scan.coverity.com and accessible to project members. On the other hand, we can probably get started without resolving this. I did see mentions of risk classification, but have not been able to find a publicly manual. Also, I found references (and examples) of overview reports that we could decide to publish as part of the release cycle (or at a fixed time period), if this is an advantage to the project.

> Do coverity impose any restrictions on the reporting of issues they have

> found, in terms of using responsible disclosure etc?

See https://scan.coverity.com/faq "Who can have access?" - but the short answer is Yes, "Our [Coverity's] approach is that of Responsible Disclosure." ... "Since projects that do not resolve their outstanding defects are leaving their users exposed to the consequences of those flaws, Coverity will work to encourage a project to resolve all of their defects. Coverity may set a deadline for the publication of all the analysis results for a project." ... not clear what this means in practice though. Coverity creates an annual report, see http://wpcme.coverity.com/wp-content/uploads/2012-Coverity-Scan-Report.pdf for last year's. This includes detailed reports for some projects. Note that Linux is part of that report and that KVM's defect density is listed as 1.54 (well above Linux average).

http://www.phoronix.com/scan.php?page=news_item&px=MTI0MDA

There is also the following note, http://en.wikipedia.org/wiki/Open-source_software_security#Coverity_scan. by which projects get classified into rungs depending on their coverity usage. The FAQ does not mention these, but the above scan report refers to a target level.

There are a few other things to note and consider, from the FAQ (everybody interested in this thread should read it)

#1: "Access to the detailed analysis results for most projects is granted only to members of the open source project, to ensure that potential security defects may be resolved before the general public sees them." (section "Who Can have access?")

#2a: "Project members signing up are required to accept a click-through license." (section "Does the project or do project members have to sign an NDA (Non-disclosure agreement)?")

#2b: "You will be granted access subject to approval by project owner or Scan administrator." (section "how do I get an account?")

In other words, there are to gates and mechanism from Coverities perspective: signing the license/service agreement online and approval by scan administrator (currently Konrad). Just something to consider when we define our process.

Lars

On Sat, Aug 31, 2013 at 10:50 PM, Matt Wilson <msw@xxxxxxxxx> wrote:

On Sat, Aug 31, 2013 at 10:36:40AM +0100, Ian Campbell wrote:
> On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:

[...]

> > 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?

+1

The "discuss in public" approach seems to work for the "distros"
mailing list. Membership requests are discussed in the public on the
"oss-security" mailing list. [1]

> 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.

This all sounds reasonable to me.

--msw

[1] http://oss-security.openwall.org/wiki/mailing-lists/distros

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

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