Re: security@ovirt.org mailing list

On Wednesday 09 November 2011 08:38:31 Chris Wright wrote: > * David Jorm (djorm(a)redhat.com) wrote: >> Hi All >> >> I would like to create a security(a)ovirt.org mailing list. The list would be used to capture reports of security flaws affecting projects under the oVirt umbrella, not for general security discussion. I would then like to create a security page on the wiki, mentioning this list and encouraging people to report flaws. The list should be private, with approval required to subscribe. I would like one of the initial subscribers to be secalert(a)redhat.com. All messages sent to this address result in an RT ticket in the Red Hat Security Response Team (SRT) queue. SRT looks at all of these tickets within one business day. >> >> What does everyone think of this idea? > Formalizing something re: security and ovirt is a great idea, thanks for > proposing. Two thoughts on the topic... > > Often projects have a security@ private list w/ just key core developers > subscribed. I'm not fundamentally opposed to secalert being subscribed, > but it does set a precedent that distros' security teams may expect to > be involved rather than notified via somehting like oss-security. > > The other thing to consider is that ovirt is an umbrella organization for > multiple projects. It's possible that each project should have a security > contact of its own, e.g. do VDSM, webui, or ovirt node developers need > to be on a private list discussing ovirt-engine security vulnerabilities > (from the point of view of information leak concerns)? > > thanks, > -chris I agree we should have a list, in one way or another. I also agree with some of the issues Chris raised. A few more points needs to be addressed; Some form of segregation of the projects is needed, however we cannot completely block information sharing since some components may share flaws, and need co-operation to resolve such issues. For instance think of a flaw in the API between engine-core and REST API or UI; all share pieces of code today. Think of a problem in the API between VDSM and engine-core. These will all require both sides in order to resolve the issue, and complete segregation will make this hard to resolve. One more thing, back at the workshop we discussed the nature of ovirt-node project. IE- will it remain based on RHEL / Fedora as it is today, or will it become a special packaging project, allowing suse-ovirt-node and ubuntu-ovirt-node. I'm not going into the discussion now, but in case we'll have suse or ubunto nodes, CVE's may affect the actual distro, so this should be carefully examined.