Hi All I would like to create a security@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@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? Thanks -- David Jorm / Red Hat Security Response Team
* David Jorm (djorm@redhat.com) wrote:
Hi All
I would like to create a security@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@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
On Wednesday 09 November 2011 08:38:31 Chris Wright wrote:
* David Jorm (djorm@redhat.com) wrote:
Hi All
I would like to create a security@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@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. -- /d "The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963)
On 11/09/2011 02:43 AM, Doron Fediuck wrote:
On Wednesday 09 November 2011 08:38:31 Chris Wright wrote:
Hi All
I would like to create a security@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@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
* David Jorm (djorm@redhat.com) wrote: 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.
I think as long as the key members from each project are on the list, and it is oVirt project wide I think it will work. If we do a private list we can control the subscriptions to maintainers or something like that. I would be interested to know if any projects have a public security list. I don't know of any, but am going to google around a bit. Carl.
* Carl Trieloff (cctrieloff@redhat.com) wrote:
I think as long as the key members from each project are on the list, and it is oVirt project wide I think it will work. If we do a private list we can control the subscriptions to maintainers or something like that. I would be interested to know if any projects have a public security list. I don't know of any, but am going to google around a bit.
I'm not familiar with any. I haven't looked, but in all the projects I've been involved in directly or indirectly the list was private. The private list can work with distros via linux-distros@openwall.org list to privately discuss things like embargo dates and oss-security@openwall.org to openly discuss security issues (CVE request, classes of bugs, etc). thanks, -chris
On 10/11/2011, at 3:36 AM, Chris Wright wrote:
* Carl Trieloff (cctrieloff@redhat.com) wrote:
I think as long as the key members from each project are on the list, and it is oVirt project wide I think it will work. If we do a private list we can control the subscriptions to maintainers or something like that. I would be interested to know if any projects have a public security list. I don't know of any, but am going to google around a bit.
I'm not familiar with any. I haven't looked, but in all the projects I've been involved in directly or indirectly the list was private. The private list can work with distros via linux-distros@openwall.org list to privately discuss things like embargo dates and oss-security@openwall.org to openly discuss security issues (CVE request, classes of bugs, etc).
If it helps as an example, the aeolus-security mailing list gives a public GPG key on our website. So, security professionals can sign/encrypt stuff to us if desired. That mailing list goes to core project members only, who have the private key, and the archives are also restricted. Seems like an ok approach, but we haven't had to actually make use of it yet. ;> Regards and best wishes, Justin Clift -- Aeolus Community Manager http://www.aeolusproject.org
On 11/09/2011 11:46 AM, Justin Clift wrote:
On 10/11/2011, at 3:36 AM, Chris Wright wrote:
I think as long as the key members from each project are on the list, and it is oVirt project wide I think it will work. If we do a private list we can control the subscriptions to maintainers or something like that. I would be interested to know if any projects have a public security list. I don't know of any, but am going to google around a bit. I'm not familiar with any. I haven't looked, but in all the projects I've been involved in directly or indirectly the list was private. The
* Carl Trieloff (cctrieloff@redhat.com) wrote: private list can work with distros via linux-distros@openwall.org list to privately discuss things like embargo dates and oss-security@openwall.org to openly discuss security issues (CVE request, classes of bugs, etc). If it helps as an example, the aeolus-security mailing list gives a public GPG key on our website. So, security professionals can sign/encrypt stuff to us if desired. That mailing list goes to core project members only, who have the private key, and the archives are also restricted.
Seems like an ok approach, but we haven't had to actually make use of it yet. ;>
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
Chris, Do you want to start a vote to add the list. suggesting a vote given the topic of the list and that it would be private. Carl.
* Carl Trieloff (cctrieloff@redhat.com) wrote:
Do you want to start a vote to add the list. suggesting a vote given the topic of the list and that it would be private.
Sure, list creation != list membership or list mechanics. FWIW, I'm fine w/ a private list including core developers nominated by the individual projects. thanks, -chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2011 09:08 AM, Chris Wright wrote:
* Carl Trieloff (cctrieloff@redhat.com) wrote:
Do you want to start a vote to add the list. suggesting a vote given the topic of the list and that it would be private.
Sure, list creation != list membership or list mechanics.
FWIW, I'm fine w/ a private list including core developers nominated by the individual projects.
+1 from an observer - private when necessary fits well with public by default.[1] - - Karsten [1] Somewhat relevant: https://www.theopensourceway.org/wiki/Communities_of_practice#Develop_both_p... (or http://bit.ly/TOSWCoPPubPriv ) - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOuuHK2ZIOBq0ODEERAh1QAKCpdl2dXkkgZQ/NkCuGVSnQ88bNIgCfaJtj NyuMy+6zPXPsGGHJBbn8gSM= =S08k -----END PGP SIGNATURE-----
On 11/09/2011 10:25 PM, Karsten 'quaid' Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/09/2011 09:08 AM, Chris Wright wrote:
* Carl Trieloff (cctrieloff@redhat.com) wrote:
Do you want to start a vote to add the list. suggesting a vote given the topic of the list and that it would be private.
Sure, list creation != list membership or list mechanics.
FWIW, I'm fine w/ a private list including core developers nominated by the individual projects.
+1 from an observer - private when necessary fits well with public by default.[1]
+1 for private security mailing list.
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.
Subscribing secalert allows us to handle reported issues in-confidence or under embargo. When security researchers who are practising responsible disclosure report issues, they often want the issue handled under embargo so that they can synchronize their own publication of the flaw with the release of a patch. There's no reason in my view that other distros' security teams can't be involved too, if they can handle issues under embargo. oss-security is publicly archived, so issues sent there can't be kept under embargo. Red Hat SRT has a set of tools that allow us to file tracking bugs for all versions of a product affected by a given flaw. Since most ovirt projects so far are using bugzilla, we can use these tools to file tracking bugs against the ovirt projects. By giving the direct feed of information to secalert, the ovirt projects will be getting triage and bug filing back, for free. Thanks David
participants (7)
-
Carl Trieloff -
Chris Wright -
David Jorm -
Doron Fediuck -
Itamar Heim -
Justin Clift -
Karsten 'quaid' Wade