Coverity + XenProject + Process?

Coverity + XenProject + Process?

[Konrad Rzeszutek Wilk]

Hey

We have a static analyzer setup for Xen called Coverity. It allows
the code to be inspected for bugs and such.

Originally I setup this so that we could make sure that there are no
bugs that cause security issues - and as such invited only folks
on the security Xen mailing list.

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?

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

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

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

Thank you.

Re: Coverity + XenProject + Process?

[David Vrabel]

On 30/08/13 16:00, Konrad Rzeszutek Wilk wrote:
> Hey
> 
> We have a static analyzer setup for Xen called Coverity. It allows
> the code to be inspected for bugs and such.
> 
> Originally I setup this so that we could make sure that there are no
> bugs that cause security issues - and as such invited only folks
> on the security Xen mailing list.

If there has been a pass already and that found no security issues, I
think the results should be made open and available to all.

Any (new) issues coverity might find in a development branch are just
bugs and not (yet) a security issues.

David

Re: Coverity + XenProject + Process?

[Ian Campbell]

On Fri, 2013-08-30 at 16:34 +0100, David Vrabel wrote:
> On 30/08/13 16:00, Konrad Rzeszutek Wilk wrote:
> > Hey
> > 
> > We have a static analyzer setup for Xen called Coverity. It allows
> > the code to be inspected for bugs and such.
> > 
> > Originally I setup this so that we could make sure that there are no
> > bugs that cause security issues - and as such invited only folks
> > on the security Xen mailing list.
> 
> If there has been a pass already and that found no security issues, I
> think the results should be made open and available to all.

The issue is that there are lots of issues, of which only a tiny
minority are going to turn out to be actual security issues. What is
needed is for someone to go through them all and classify them.

> Any (new) issues coverity might find in a development branch are just
> bugs and not (yet) a security issues.

Unless the relevant breakage got backported before the pass.

Ian.

Re: Coverity + XenProject + Process?

[Ian Campbell]

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@xen.org 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@Xen.org 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@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Coverity + XenProject + Process?

[Matt Wilson]

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@Xen.org 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

Re: Coverity + XenProject + Process?

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 4775 bytes --]

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@linux.com> 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@Xen.org 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@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 7436 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Coverity + XenProject + Process?

[Ian Campbell]

On Mon, 2013-09-02 at 10:57 +0100, Lars Kurth wrote:
> 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.

Right. I think these questions are largely orthogonal to the key
question which is who can see the private issues and under what
circumstances we would trust someone with such access etc.

Ian.

Re: Coverity + XenProject + Process?

[Steven Maresca]

[-- Attachment #1.1: Type: text/plain, Size: 7120 bytes --]

Just wanted to throw my hat in the ring as a willing volunteer, even though
I
recognize we have yet settle on a process for officially volunteering.

To get it out of the way immediately: I am entirely content to forfeit any
sort
of 'discoverer' privileges. In this respect, I care much more about the
integrity of Xen and its components than I do about some sort of temporary
notoriety. Similarly, I will readily sign a non-disclosure agreement,
should one
be required.

Despite being involved with Xen in some capacity for a long time, my full
time
work is purely in the security domain, employed by a large public
university in
its security office. In addition to incident response and risk/vulnerability
assessment, code audits are a major aspect of my efforts, at the university
and
beyond. The requirements, philosophies, and general procedures of similar
undertakings are part of my daily responsibilities.

If I were to become involved with a Xen code audit process, I would be
comfortable classifying issues by scope, severity, and relative risk, as
well
as proposing fixes as appropriate.  From a development perspective, I am
familiar with a variety of Xen components, including the low level toolstack
and hypervisor itself. Most recently, I have been focused upon
mem_access/mem_events and experimenting with using clang/LLVM at
build time.

Motivation for volunteering is simple: In my private work, I build software
and
infrastructure intended to inspect and ensure the sanctity of valuable
systems,
including tools for reverse engineering, and a framework for virtual machine
memory analysis. To do so, I utilize very particular features of Xen and
depend
heavily upon its integrity as a matter of course. A variety static analysis
tools,
fuzzers, etc., are regularly used in dual pursuit of solid development and
remediation of vulnerabilities and weaknesses. My needs therefore overlap
strongly with those needs and expectations of the Xen community.

Steve


On Mon, Sep 2, 2013 at 5:57 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:

> 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@linux.com> 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@Xen.org 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@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

[-- Attachment #1.2: Type: text/html, Size: 10430 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Coverity + XenProject + Process?

[Steven Maresca]

[-- Attachment #1.1: Type: text/plain, Size: 7468 bytes --]

On Wed, Sep 4, 2013 at 6:20 PM, Steven Maresca <steve@zentific.com> wrote:

> Just wanted to throw my hat in the ring as a willing volunteer, even
> though I
> recognize we have yet settle on a process for officially volunteering.
>
> To get it out of the way immediately: I am entirely content to forfeit any
> sort
> of 'discoverer' privileges. In this respect, I care much more about the
> integrity of Xen and its components than I do about some sort of temporary
> notoriety. Similarly, I will readily sign a non-disclosure agreement,
> should one
> be required.
>
> Despite being involved with Xen in some capacity for a long time, my full
> time
> work is purely in the security domain, employed by a large public
> university in
> its security office. In addition to incident response and
> risk/vulnerability
> assessment, code audits are a major aspect of my efforts, at the
> university and
> beyond. The requirements, philosophies, and general procedures of similar
> undertakings are part of my daily responsibilities.
>
> If I were to become involved with a Xen code audit process, I would be
> comfortable classifying issues by scope, severity, and relative risk, as
> well
> as proposing fixes as appropriate.  From a development perspective, I am
> familiar with a variety of Xen components, including the low level
> toolstack
> and hypervisor itself. Most recently, I have been focused upon
> mem_access/mem_events and experimenting with using clang/LLVM at
> build time.
>
> Motivation for volunteering is simple: In my private work, I build
> software and
> infrastructure intended to inspect and ensure the sanctity of valuable
> systems,
> including tools for reverse engineering, and a framework for virtual
> machine
> memory analysis. To do so, I utilize very particular features of Xen and
> depend
> heavily upon its integrity as a matter of course. A variety static
> analysis tools,
> fuzzers, etc., are regularly used in dual pursuit of solid development and
> remediation of vulnerabilities and weaknesses. My needs therefore overlap
> strongly with those needs and expectations of the Xen community.
>
> Steve
>
>
> On Mon, Sep 2, 2013 at 5:57 AM, Lars Kurth <lars.kurth.xen@gmail.com>wrote:
>
>> 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@linux.com> 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@Xen.org 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@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>>
> And sorry for top-posting. Crappy mail client.

Steve

[-- Attachment #1.2: Type: text/html, Size: 10920 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Coverity + XenProject + Process?

[Ian Campbell]

On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:
> Hey
> 
> We have a static analyzer setup for Xen called Coverity. It allows
> the code to be inspected for bugs and such.
> 
> Originally I setup this so that we could make sure that there are no
> bugs that cause security issues - and as such invited only folks
> on the security Xen mailing list.
> 
> 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?

This conversation and the decision is on going to take a while.

In the meantime we (security@ or xen-devel@) have received offers of
help from Matthew Daley, Andrew Cooper and Steven Maresca. All three are
well known to us and IMHO trustworthy. Matthew and Andrew have been
involved in both disclosing and helping to resolve multiple security
issues in the past. I don't think Steven has been involved in security
disclosure stuff (apologies Steven if I've forgotten) but has none the
less been active in Xen and with various security related aspects of the
project.

Given that I would like to propose that we give all three of them access
while the policy conversation is on going.

Any objections? If so then please raise them by the end of business this
Sunday (8 September).

Ian.

Re: Coverity + XenProject + Process?

[Konrad Rzeszutek Wilk]

On Thu, Sep 05, 2013 at 10:26:38AM +0100, Ian Campbell wrote:
> On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:
> > Hey
> > 
> > We have a static analyzer setup for Xen called Coverity. It allows
> > the code to be inspected for bugs and such.
> > 
> > Originally I setup this so that we could make sure that there are no
> > bugs that cause security issues - and as such invited only folks
> > on the security Xen mailing list.
> > 
> > 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?
> 
> This conversation and the decision is on going to take a while.
> 
> In the meantime we (security@ or xen-devel@) have received offers of
> help from Matthew Daley, Andrew Cooper and Steven Maresca. All three are
> well known to us and IMHO trustworthy. Matthew and Andrew have been
> involved in both disclosing and helping to resolve multiple security
> issues in the past. I don't think Steven has been involved in security
> disclosure stuff (apologies Steven if I've forgotten) but has none the
> less been active in Xen and with various security related aspects of the
> project.
> 
> Given that I would like to propose that we give all three of them access
> while the policy conversation is on going.

+1
> 
> Any objections? If so then please raise them by the end of business this
> Sunday (8 September).
> 
> Ian.
> 
> 

Re: Coverity + XenProject + Process?

[Matt Wilson]

On Thu, Sep 05, 2013 at 10:26:38AM +0100, Ian Campbell wrote:
> On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:
> > Hey
> > 
> > We have a static analyzer setup for Xen called Coverity. It allows
> > the code to be inspected for bugs and such.
> > 
> > Originally I setup this so that we could make sure that there are no
> > bugs that cause security issues - and as such invited only folks
> > on the security Xen mailing list.
> > 
> > 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?
> 
> This conversation and the decision is on going to take a while.
> 
> In the meantime we (security@ or xen-devel@) have received offers of
> help from Matthew Daley, Andrew Cooper and Steven Maresca. All three are
> well known to us and IMHO trustworthy. Matthew and Andrew have been
> involved in both disclosing and helping to resolve multiple security
> issues in the past. I don't think Steven has been involved in security
> disclosure stuff (apologies Steven if I've forgotten) but has none the
> less been active in Xen and with various security related aspects of the
> project.
> 
> Given that I would like to propose that we give all three of them access
> while the policy conversation is on going.
> 
> Any objections? If so then please raise them by the end of business this
> Sunday (8 September).

+1

--msw

Re: Coverity + XenProject + Process?

[Konrad Rzeszutek Wilk]

On Sun, Sep 08, 2013 at 03:13:41PM -0700, Matt Wilson wrote:
> On Thu, Sep 05, 2013 at 10:26:38AM +0100, Ian Campbell wrote:
> > On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:
> > > Hey
> > > 
> > > We have a static analyzer setup for Xen called Coverity. It allows
> > > the code to be inspected for bugs and such.
> > > 
> > > Originally I setup this so that we could make sure that there are no
> > > bugs that cause security issues - and as such invited only folks
> > > on the security Xen mailing list.
> > > 
> > > 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?
> > 
> > This conversation and the decision is on going to take a while.
> > 
> > In the meantime we (security@ or xen-devel@) have received offers of
> > help from Matthew Daley, Andrew Cooper and Steven Maresca. All three are
> > well known to us and IMHO trustworthy. Matthew and Andrew have been
> > involved in both disclosing and helping to resolve multiple security
> > issues in the past. I don't think Steven has been involved in security
> > disclosure stuff (apologies Steven if I've forgotten) but has none the
> > less been active in Xen and with various security related aspects of the
> > project.
> > 
> > Given that I would like to propose that we give all three of them access
> > while the policy conversation is on going.
> > 
> > Any objections? If so then please raise them by the end of business this
> > Sunday (8 September).
> 
> +1

No objections either. +1 for all three!
> 
> --msw

Re: Coverity + XenProject + Process?

[Ian Campbell]

On Mon, 2013-09-09 at 09:30 -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Sep 08, 2013 at 03:13:41PM -0700, Matt Wilson wrote:
> > On Thu, Sep 05, 2013 at 10:26:38AM +0100, Ian Campbell wrote:
> > > On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:
> > > > Hey
> > > > 
> > > > We have a static analyzer setup for Xen called Coverity. It allows
> > > > the code to be inspected for bugs and such.
> > > > 
> > > > Originally I setup this so that we could make sure that there are no
> > > > bugs that cause security issues - and as such invited only folks
> > > > on the security Xen mailing list.
> > > > 
> > > > 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?
> > > 
> > > This conversation and the decision is on going to take a while.
> > > 
> > > In the meantime we (security@ or xen-devel@) have received offers of
> > > help from Matthew Daley, Andrew Cooper and Steven Maresca. All three are
> > > well known to us and IMHO trustworthy. Matthew and Andrew have been
> > > involved in both disclosing and helping to resolve multiple security
> > > issues in the past. I don't think Steven has been involved in security
> > > disclosure stuff (apologies Steven if I've forgotten) but has none the
> > > less been active in Xen and with various security related aspects of the
> > > project.
> > > 
> > > Given that I would like to propose that we give all three of them access
> > > while the policy conversation is on going.
> > > 
> > > Any objections? If so then please raise them by the end of business this
> > > Sunday (8 September).
> > 
> > +1
> 
> No objections either. +1 for all three!

You said this on Friday too, get some sleep dude ;-)

Anyway, no objections and the deadline has passed. So I think you can
give the three of them access. (I haven't looked but I don't think I'm
capable?)

Ian.

Re: Coverity + XenProject + Process?

[Konrad Rzeszutek Wilk]

On Mon, Sep 09, 2013 at 03:20:25PM +0100, Ian Campbell wrote:
> On Mon, 2013-09-09 at 09:30 -0400, Konrad Rzeszutek Wilk wrote:
> > On Sun, Sep 08, 2013 at 03:13:41PM -0700, Matt Wilson wrote:
> > > On Thu, Sep 05, 2013 at 10:26:38AM +0100, Ian Campbell wrote:
> > > > On Fri, 2013-08-30 at 11:00 -0400, Konrad Rzeszutek Wilk wrote:
> > > > > Hey
> > > > > 
> > > > > We have a static analyzer setup for Xen called Coverity. It allows
> > > > > the code to be inspected for bugs and such.
> > > > > 
> > > > > Originally I setup this so that we could make sure that there are no
> > > > > bugs that cause security issues - and as such invited only folks
> > > > > on the security Xen mailing list.
> > > > > 
> > > > > 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?
> > > > 
> > > > This conversation and the decision is on going to take a while.
> > > > 
> > > > In the meantime we (security@ or xen-devel@) have received offers of
> > > > help from Matthew Daley, Andrew Cooper and Steven Maresca. All three are
> > > > well known to us and IMHO trustworthy. Matthew and Andrew have been
> > > > involved in both disclosing and helping to resolve multiple security
> > > > issues in the past. I don't think Steven has been involved in security
> > > > disclosure stuff (apologies Steven if I've forgotten) but has none the
> > > > less been active in Xen and with various security related aspects of the
> > > > project.
> > > > 
> > > > Given that I would like to propose that we give all three of them access
> > > > while the policy conversation is on going.
> > > > 
> > > > Any objections? If so then please raise them by the end of business this
> > > > Sunday (8 September).
> > > 
> > > +1
> > 
> > No objections either. +1 for all three!
> 
> You said this on Friday too, get some sleep dude ;-)

<sigh>
> 
> Anyway, no objections and the deadline has passed. So I think you can
> give the three of them access. (I haven't looked but I don't think I'm
> capable?)

Just did it. All three should have gotten an invite. Pls email if you haven't.

> 
> Ian.
>