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.
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
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.
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
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
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
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.
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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. > >
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
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). > > +1No objections either. +1 for all three!> > --msw
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.
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. >
Apparently Analagous Threads
- [PATCH] xen/gnttab: leave lazy MMU mode in the case of a m2p override failure
- [PATCH] xen/x86: add a comment regarding how to get the VCPU ID on HVM
- [PATCH] various Xen fixes for v3.6 (v1).
- [PATCH v2] xen/x86: add a comment regarding how to get the VCPU ID on HVM
- Security disclosure process discussion update