Re: [Qemu-devel] KVM call agenda for 2014-04-28

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Apr 29, 2014 at 03:31:32PM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
> 
> > On Tue, Apr 29, 2014 at 02:33:58PM +0200, Markus Armbruster wrote:
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >> 
> >> > On 29 April 2014 11:09, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >> 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.
> >> 
> >> 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.
> 
> 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.

-- 
MST