KVM call agenda for 2014-04-28
Hi
Please, send any topic that you are interested in covering.
Thanks, Juan.
Call details:
15:00 CEST
13:00 UTC
09:00 EDT
Every two weeks
If you need phone number details, contact me privately.
What is the Phone numbers of the call?
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Juan Quintela
Sent: Monday, April 28, 2014 1:13 PM
To: KVM devel mailing list; qemu list
Subject: KVM call agenda for 2014-04-28
Hi
Please, send any topic that you are interested in covering.
Thanks, Juan.
Call details:
15:00 CEST
13:00 UTC
09:00 EDT
Every two weeks
If you need phone number details, contact me privately.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 1 line · Venkateswara Rao Nandigam
What is the Phone numbers of the call?
Can you told me where you are based, and I can search for
I hope one of the numbers is good for you O:-)
Bi-weekly conference to discuss kvm and qemu issues.
Conference Code: 5402697718
For the phone numbers, visit that page:
https://www-emea.intercallonline.com/listNumbersByCode.action?confCode=5402697718
If you have any problem, let me know.
Quoted 26 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Juan Quintela
Sent: Monday, April 28, 2014 1:13 PM
To: KVM devel mailing list; qemu list
Subject: KVM call agenda for 2014-04-28Hi
Please, send any topic that you are interested in covering.
Thanks, Juan.
Call details:
15:00 CEST
13:00 UTC
09:00 EDTEvery two weeks
If you need phone number details, contact me privately.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · Juan Quintela
Hi
Please, send any topic that you are interested in covering.
[...]
I'd like to have these things settled sooner than five minutes before the scheduled hour, so here goes: call or no call? Agenda?
Quoted 10 lines · Markus Armbruster
Quoted 3 lines · Juan Quintela
Hi
Please, send any topic that you are interested in covering.
[...]
I'd like to have these things settled sooner than five minutes before the scheduled hour, so here goes: call or no call? Agenda?
If not too late, I'd like to discuss our security process.
Do we as the project generally agree to use responsible disclosure policy
http://en.wikipedia.org/wiki/Responsible_disclosure ?
Quoted 3 lines · Michael S. Tsirkin
If not too late, I'd like to discuss our security process.
Do we as the project generally agree to use responsible disclosure policy
http://en.wikipedia.org/wiki/Responsible_disclosure ?
I think something like that makes sense. I'm a bit wary that we write up some complicated policy that we're not then in practice capable of executing given our level of resources. We should certainly write out some documentation though...
thanks
-- PMM
Quoted 5 lines · Peter Maydell
Quoted 3 lines · Michael S. Tsirkin
If not too late, I'd like to discuss our security process.
Do we as the project generally agree to use responsible disclosure policy
http://en.wikipedia.org/wiki/Responsible_disclosure ?
Quoted 7 lines
I think something like that makes sense. I'm a bit wary that we write up some complicated policy that we're not then in practice capable of executing given our level of resources. We should certainly write out some documentation though...
thanks
-- PMM
I didn't have anything complex in mind.
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcess
Signature · 1 line
MST
Quoted 4 lines · Michael S. Tsirkin
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcess
Looks generally OK I guess. I'd drop the 'how to use pgp' section -- anybody who cares will already know how to send us PGP email.
thanks
-- PMM
Quoted 8 lines · Peter Maydell
Quoted 4 lines · Michael S. Tsirkin
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcessLooks generally OK I guess. I'd drop the 'how to use pgp' section -- anybody who cares will already know how to send us PGP email.
The first paragraph under "How to Contact Us Securely" is fine, the rest seems redundant for readers familiar with PGP, yet hardly sufficient for the rest.
One thing I like about Libvirt's Security Process page[*] is they give an idea on embargo duration.
Quoted 15 lines · Markus Armbruster
Quoted 8 lines · Peter Maydell
Quoted 4 lines · Michael S. Tsirkin
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcessLooks generally OK I guess. I'd drop the 'how to use pgp' section -- anybody who cares will already know how to send us PGP email.
The first paragraph under "How to Contact Us Securely" is fine, the rest seems redundant for readers familiar with PGP, yet hardly sufficient for the rest.
Quoted 5 lines
One thing I like about Libvirt's Security Process page[*] is they give an idea on embargo duration.
I don't have an idea though. Do you?
Let's try the process for a while, see how well we manage in practice.
Quoted 11 lines · Markus Armbruster
Quoted 8 lines · Peter Maydell
Quoted 4 lines · Michael S. Tsirkin
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcessLooks generally OK I guess. I'd drop the 'how to use pgp' section -- anybody who cares will already know how to send us PGP email.
Quoted 6 lines
The first paragraph under "How to Contact Us Securely" is fine, the rest seems redundant for readers familiar with PGP, yet hardly sufficient for the rest.
One thing I like about Libvirt's Security Process page[*] is they give an idea on embargo duration.
FWIW I picked the "2 weeks" length myself a completely arbitrary timeframe. We haven't stuck to that strictly - we consider needs of each vulnerability as it is triaged to determine the minimum practical embargo time. So think of "2 weeks" as more of a guiding principal to show the world that we don't believe in keeping issues under embargo for very long periods of time.
Regards,
Daniel
Signature · 4 lines
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Quoted 16 lines · Daniel P. Berrange
Quoted 15 lines · Markus Armbruster
Quoted 8 lines · Peter Maydell
Quoted 4 lines · Michael S. Tsirkin
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcessLooks generally OK I guess. I'd drop the 'how to use pgp' section -- anybody who cares will already know how to send us PGP email.
The first paragraph under "How to Contact Us Securely" is fine, the rest seems redundant for readers familiar with PGP, yet hardly sufficient for the rest.
Quoted 8 lines
Quoted 2 lines
One thing I like about Libvirt's Security Process page[*] is they give an idea on embargo duration.
FWIW I picked the "2 weeks" length myself a completely arbitrary timeframe. We haven't stuck to that strictly - we consider needs of each vulnerability as it is triaged to determine the minimum practical embargo time. So think of "2 weeks" as more of a guiding principal to show the world that we don't believe in keeping issues under embargo for very long periods of time.
Pretty much the way I read it :)
The point I care about is a commitment to getting fixes out quickly, making clear we're not going to abuse "responsible disclosure" to cover dragging of feet and deflecting blame.
Quoted 27 lines · Markus Armbruster
Quoted 16 lines · Daniel P. Berrange
Quoted 15 lines · Markus Armbruster
Quoted 8 lines · Peter Maydell
Quoted 4 lines · Michael S. Tsirkin
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcessLooks generally OK I guess. I'd drop the 'how to use pgp' section -- anybody who cares will already know how to send us PGP email.
The first paragraph under "How to Contact Us Securely" is fine, the rest seems redundant for readers familiar with PGP, yet hardly sufficient for the rest.
Quoted 8 lines
Quoted 2 lines
One thing I like about Libvirt's Security Process page[*] is they give an idea on embargo duration.
FWIW I picked the "2 weeks" length myself a completely arbitrary timeframe. We haven't stuck to that strictly - we consider needs of each vulnerability as it is triaged to determine the minimum practical embargo time. So think of "2 weeks" as more of a guiding principal to show the world that we don't believe in keeping issues under embargo for very long periods of time.
Quoted 5 lines
Pretty much the way I read it :)
The point I care about is a commitment to getting fixes out quickly, making clear we're not going to abuse "responsible disclosure" to cover dragging of feet and deflecting blame.
Well it does say right at the top: "we aim to take immediate action to address serious security-related problems that involve our product". I don't see how by myself I can make a more specific commitment. If multiple maintainers can make a stronger guarantee, we can document it (it's a wiki :)
It won't be easy to retract a promise once given, so let's tread carefully here.
Signature · 1 line
MST
Quoted 14 lines · Michael S. Tsirkin
Quoted 5 lines · Peter Maydell
Quoted 3 lines · Michael S. Tsirkin
If not too late, I'd like to discuss our security process.
Do we as the project generally agree to use responsible disclosure policy
http://en.wikipedia.org/wiki/Responsible_disclosure ?Quoted 7 lines
I think something like that makes sense. I'm a bit wary that we write up some complicated policy that we're not then in practice capable of executing given our level of resources. We should certainly write out some documentation though...
thanks
-- PMM
Quoted 6 lines
I didn't have anything complex in mind.
Let's just make clear how to contact us securely, when to contact that list, and what we'll do with the info. I cobbled together the following:
http://wiki.qemu.org/SecurityProcess
Looks good. Responsible disclosure plus who to contact should be enough to help people report security issues properly.
Stefan
Quoted 10 lines · Markus Armbruster
Quoted 3 lines · Juan Quintela
Hi
Please, send any topic that you are interested in covering.
[...]
I'd like to have these things settled sooner than five minutes before the scheduled hour, so here goes: call or no call? Agenda?
I don't think we managed to fully conclude on a good way to assign sysbus/platbus devices into the guest using configuration data only, did we? Would be good to put that on today's agenda again and conclude on something, so people who need it can work into the right direction.
Alex