Re: About 'qemu-security' mailing list

[Daniel P . Berrangé]

On Fri, Sep 11, 2020 at 07:50:24PM +0530, P J P wrote:
>   Hello all,
> 
> Recently while conversing with DanPB this point came up
> 
>    -> https://www.qemu.org/contribute/security-process/
> 
> * Currently QEMU security team is a handful of individual contacts which
>   restricts community participation in dealing with these issues.
> 
> * The Onus also lies with the individuals to inform the community about QEMU
>   security issues, as they come in.
> 
> 
> Proposal: (to address above limitations)
> =========
> 
> * We set up a new 'qemu-security' mailing list.
> 
> * QEMU security issues are reported to this new list only.
> 
> * Representatives from various communities subscribe to this list. (List maybe
>   moderated in the beginning.)

For libvirt we have the list membership targetted as being nominated
security representatives of any downstream distributor of libvirt.
ie essentially the security people from various OS vendors. Other
members can be considered on a case by case basis if they want to
make their case.

FWIW, we have the libvirt-security list moderated at all times, and
manually approve mails from non-members in order to prevent it being
a spam trap. Manual moderation is not too much of a burden assuming
the rate of CVEs isn't huge !

> * As QEMU issues come in, participants on the 'qemu-security' list shall
>   discuss and decide about how to triage them further.

For libvirt-security, members are required to respect the project's
declared embargo policy. This sets as a 2 week maximum by default,
anything beyond 2 weeks has to be explicitly requested as appropriate
and not have objection from members of the list.  QEMU doesn't set any
explicit default embargo period right now just saying it is via mutual
agreement:

  https://www.qemu.org/contribute/security-process/

this might want to be clarified to set a default expectation, because
with a list of members you won't want to wait for everyone to explicitly
approve a date. You want people to know what to expect as a default
upfront, and only have the discussions in cases which need more time.

I'm not saying QEMU has to be 2 weeks - perhaps just look at a sample
of the past year's CVEs in QEMU and use them as a guide for a reasonable
default period to handle or publish the issues.

> Please kindly let us know your views about it. I'd appreciate if you have
> any suggestions/inputs/comments about the same.

I'm in favour of this, since this is what we have done for libvirt
upstream security response handling, and it has been a clear improvement
on our previous process involving CC'ing individual developers.

It makes the security response process more of a level playing field for
all downstreams QEMU distributors.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|